From: Brad Phelan <phelan@...>
Date: 2007-09-27T14:15:07+09:00
Subject: Re: Recent Criticism about Ruby (Scalability, etc.)

M. Edward (Ed) Borasky wrote:
> Brad Phelan wrote:
>> With regards to Python/Ruby speed issues. I am currently watching a
>> complex scheduling algorithm ticking by very slowly in a shell while I
>> write this post. The algorithm should should have been written in C/C++
>> and not in Python/Psyco or Ruby and I am going nuts waiting for it to
>> complete.
>>
>> ( BTW I didn't write it )
> 
> "Complex scheduling algorithm" means different things to different
> people. Is it slow because the algorithm sucks or slow because it's not
> written in C/C++? What kind of scheduling is it -- combinatorial?
> 

I have never looked at the algorithm myself. It is a TDMA message 
scheduling algorithm. Given a set of messages on a time partitioned bus, 
with multiple transmitters and receivers find the optimal message 
schedule. It is not too different from the classic M$ Project scheduling 
really. However you have thousands of messages to schedule and many 
constraints. Still I am not sure that waiting 2 minutes to several hours 
for a schedule to complete would occur if exactly the same algorithm was 
written in C rather than Python. This is pure speculation however as 
I've never had time to look over it myself and make a proper judgment.

However the argument from the developers is that real customers of the 
tool rarely run a schedule. Once the schedule has been fixed it is 
rarely changed. Therefore the pain of waiting for 5 minutes or even a 
few hours in the case of a large schedule is little pain in the overall 
scheme of a project that may last many years.

The only reason it bugs me is that I am constantly running schedules to 
generate test cases for some other downstream code I am running. It 
therefore causes me pain in ways it would not necessarily do for a real 
customer. This brings us round to the original argument I guess. Perhaps 
in this case Python is suitable. It is easy to code, and easy to 
analyze, debug and maintain. The slowness is not a huge factor because 
the customer just doesn't require it to be "fast"

B