scripting languages vs statically compiled ones

Alex Martelli aleaxit at yahoo.com
Fri Oct 29 01:00:57 CEST 2004


kosh <kosh at aesaeion.com> wrote:
   ...
> Here is the method I see on making programs fast in python.

  [[ snipped lots of well-argued explanations ]]

I also like Kent Beck's summary of basically the same ideas:

    Make it work.  Make it right.  Make it fast.

corresponding to your point 1, 2/3, and 4/7 respectively.

And of course, as part of [1] one SHOULD have a good battery of unit
tests, too.  If one doesn't, [1] isn't really complete -- how does one
_know_ one's program does work?  That battery of unit tests, religiously
rerun at each refactoring, simplification, speedup, and reuse, will be
the best help throughout the 2->7 trip, giving you faster development
and more confidence at each step.

A couple specific comments...:

> Step 6: Look for outside libraries to use like numarray, pil etc. It is better

Sometimes you can also reuse C-interfaced dynamic libraries that way,
via Thomas Heller's 'ctypes' extension.  Since you do have the overhead
of interfacing, that will give you substantial speedup only if each call
into the C-interfaced library does a lot of work, of course.

> Step 7: As a last resort if your program is still not fast enough go ahead and
> write code in a lower level language and call it from python. However be

Here, too, look first for existing, reusable (preferably with-source!)
libraries that can do most of the work you need, leaving your code
mostly as a thin glue, possibly just a bit of looping, custom logic,
etc.  Pyrex can often be the best 'lower level language' to use here,
because its level isn't _that_ much lower, necessarily.  You can start
with Pyrex code that looks 90% like Python, and descend gracefully if
that's needed...


An excellent post - thanks!


Alex



More information about the Python-list mailing list