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