Python execution speed

[Peter Hansen]

Fernando Pérez wrote:
> 
> > I'm curious, however, why you believe you need to optimize Python's
> > execution speed so much?  Do you have some application which is not
> > performing adequately?  The usual approach is simply to profile the
> > code and recode the "hot spot" in C.
> 
> I can mention one: scientific computing. Python is becoming very popular in
> that field, and Numeric goes a long way.  But sometimes it's not enough, and
> being saved from dropping down to C for anything but the truly ugliest would
> be a big blessing. And yes, in scientific computing, things are *never* fast
> enough. If you can improve the speed of a code even by a factor of 2 only,
> that can be big news. Waiting for 2 days is still better than waiting for 4
> days for your simulation to finish.

I understand these issues, but I really wanted to know why the *OP*
thought he needed more speed (which I inferred was the only serious 
advantage he felt he'd found with LISP over Python).

I certainly know of applications which need more speed.  I just 
don't think those applications would be the kind involved in a 
decision such as "should I switch from Python to LISP?"

I thought I smelled in the emphasis on speed the common phenomenon
of a programmer picking the faster of two languages when higher
speed than that already provided by the slower of the two 
was *not* a requirement, at the expense of less "tangible" benefits 
such as ease of maintenance and so forth.

(And all that without going into the point about how changing
Python to a compiled language, or going with something like C,
let alone LISP, is not likely to improve the performance of 
scientific computing over that provided by an efficient library 
such as Numeric nearly so much as it would in other areas.)

-- 
----------------------
Peter Hansen, P.Eng.
peter at engcorp.com