Speed?

[EP]

On questions of the suitability of Python for CGI, embedded apps, etc.,
execution speed comes to mind. I previously read some comparisons which
did not show Python in a good light in this regard: i.e. Python is slow
compared to Perl, C++, Java.

http://www.flat222.org/mac/bench/

Is there more authoritative and current information IRT speed comparisons?

Is newer Python any faster?

Also, if Python is a bit slower in execution than some alternative
languages, what do others do in practice to speed it up, and how much of
that optimization do they do? Or is a slower speed to be accepted like one
learns to accept that their lovely bride takes a long time getting ready to
go out ?

TIA,


Eric

P.S. I tried to replicate the simple "console test" with Python 2.3 on my
PC. Using the Windows command prompt, on a reasonably modern PC (128MB
RAM, 1.3 AMD chip), I clocked 72.45 seconds to print the numbers up to
999,999, which is more than 3x as long as the results reported in the link
given.

Then running the same program out of IDLE I clocked 627.48 seconds printing
the numbers only up to 99,999. Perhaps that's a caution about launching
any large processes out of IDLE? Here's the test script:

import time

def loop_time():
start=time.time ()
for x in xrange(1000000) :
print x
end=time.time()
exectime=end-start
return exectime

nada=raw_input( 'Press return when ready')
run=loop_time()
print 'Timed loop ran for: '+str(run)+' seconds'

[PoD]

Re: Speed?

On Fri, 02 Jan 2004 23:01:15 -0800, EP wrote:
[color=blue]
>
> On questions of the suitability of Python for CGI, embedded apps, etc.,[/color]

Most of the time taken by that test is outputting to the screen.
I tried you script in various environments

90x45 xterm 54.5 seconds
80x10 xterm 35.6
text console 26.2
minimised xterm 25.0

Run in Idle, the output goes to a TkInter text widget so I'm not surprised
it's so slow.

[Peter Hansen]

Re: Speed?

EP wrote:[color=blue]
>
> On questions of the suitability of Python for CGI, embedded apps, etc.,
> execution speed comes to mind. I previously read some comparisons which
> did not show Python in a good light in this regard: i.e. Python is slow
> compared to Perl, C++, Java.
>
> http://www.flat222.org/mac/bench/
>
> Is there more authoritative and current information IRT speed comparisons?
>
> Is newer Python any faster?
>
> Also, if Python is a bit slower in execution than some alternative
> languages, what do others do in practice to speed it up, and how much of
> that optimization do they do? Or is a slower speed to be accepted like one
> learns to accept that their lovely bride takes a long time getting ready to
> go out ?[/color]

I would question the wisdom of using any generic benchmark (such as the
"console output test" you included) to make decisions about adoption of
key technologies.

Identify the core characteristics of your intended application, code up
a simple benchmark which contains representative code, and see how it
stacks up against the competition.

We did this with Python on one embedded system we were considering,
with a benchmark that included threading, memory allocation and releasing,
some simple math, and lots of string operations. The results told us
much more than PyStone or something similar would have, and gave us much
more confidence in the results.

And with Python, of course, it's almost trivial to do this kind of
thing, compared to some other languages. Sigh.

-Peter

[Skip Montanaro]

Re: Speed?


[ 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.

Skip

[Peter Hansen]

Re: Speed?

Skip Montanaro wrote:[color=blue]
>
> [ 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.[/color]

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