Speed?

[Peter Hansen]

Skip Montanaro wrote:
> 
>     [ on creating benchmarks ]
> 
>     Peter> And with Python, of course, it's almost trivial to do this kind
>     Peter> of thing, compared to some other languages.  Sigh.
> 
> Which was just another data point in your decision, right?  After all, if
> Python is so much easier to write your benchmarks in than some/most/all of
> the alternatives, that has to factor into the choice of implementation
> language.

Well, I suppose it would have been a factor in the decision, if the
decision had really been about which language to use.  In fact in this
case we had already picked Python as a key technology, but needed to
see whether the performance of the hardware was adequate to support its
use.  Doing it with C was an alternative, but we'd already tried a 
prototype with C and concluded that while performance was fine, naturally,
we would not complete the required feature set in our lifetimes (or at
least in our funding's lifetime ;-) ).

To be completely honest: we ended up picking faster hardware in the long
run, but the choice was more because the trial platform was too limited
in RAM and ROM memory (1MB each) and had an inadequate development 
platform.  The final choice (as I mentioned in another thread today) uses
32MB RAM and ROM (Compact Flash actually) and happens to run at 100MHz
instead of the 33MHz of the first one.

Tying this in with yet another thread: we have spent next to no time
optimizing, so far, because we're still adding features and making things
work.  I firmly believe we could have optimized the code for the 
original 33MHz system to a point where it would have run acceptably,
and still in much less time than it would have taken to get a C version
running (that was the alternative possibility).  I'm just happy we 
were able to buy our way out of having to spend a lot of time optimizing.

In summary: we picked Python for reasons relating to ease of use
(development and maintenance) and flexibility, and performance was 
really not a significant issue.  As I've said before, we've written 
literally hundreds of programs with it, ranging from small utilities 
to major products, and have only *very* rarely had to pause to consider
performance and spend time optimizing anything.  Python is *not* slow!

-Peter