Python future performance and speed

[Tim Churches]

On Mon, 2004-08-23 at 00:24, Roy Smith wrote:
> Tim Churches <tchur at optushome.com.au> wrote:
> > As a population health epidemiologist whose stock-in-trade is
> > manipulation and analysis of large health data sets, I have to say that
> > Python's run-time speed is almost always much faster than I would have
> > expected from such a dynamic language, but also almost always much
> > slower than I would like, especially when compared to widely-used (but
> > vastly expensive and sprawling) data manipulation environments such as
> > SAS system (see http://www.sas.com) which is the "industry standard" in
> > my particular field.
> 
> It should not be surprising at all that a general-purpose tool will be 
> beaten by a domain-specific tool in that domain.  SAS, as you say, is 
> designed to munch huge numeric data sets.  That is its only reason for 
> existing, and it's got 20 or 30 years of development effort behind it to 
> make it do that one task as fast as possible.

Sure, and as a programming environment SAS is both primitive (eg still
has no way to easily create user-defined functions in its main language,
and is forced to rely on macros instead) and confusing (since it needs
five or six distinct sub-languages to cope with both special-purpose and
general-purpose programming tasks eg uses Java called from its own PL/1
and Fortran-influenced "data step" language to do many things - yuck!)
when compared to Python. However, none of that is a reason for not to
wish that Python were faster than it is in some circumstances - mostly
when doing dumb stuff like iterating over a file. That's why Psyco and
increasingly Pyrex are so valuable, and why the fruits of the Starkiller
and Pypy projects are so eagerly anticipated.
-- 

Tim C

PGP/GnuPG Key 1024D/EAF993D0 available from keyservers everywhere
or at http://members.optushome.com.au/tchur/pubkey.asc
Key fingerprint = 8C22 BF76 33BA B3B5 1D5B  EB37 7891 46A9 EAF9 93D0