Fast Python (was: source code size metric)

[David Mertz]

Andrew Koenig <ark at research.att.com> wrote previously:
|I'm presently trying to implement some pattern-matching algorithms in
|C++ (which I know very well) and Python (which I know only moderately
|well).  What I'm finding is that the most natural way to express these
|particular algorithms in Python is quite a bit different from the most
|natural way to express them in C++...the C++ version is *much*
|faster (between a factor of 10 and 100 in informal tests).

Without knowing the problem precisely, I could be wrong about the
following ideas.  But they seem likely.

If you'd like to do pattern matching in Python, and speed is an issue,
one likely technique is to use mx.TextTools, with its very fast state
engine.  However, mx.TextTools is difficult to use, and for many problem
using SimpleParse on top of it makes things easier.  If you can specify
patterns in an EBNF grammar, SimpleParse+mx.TextTools can recognize them
(and process them further).

Moreover, using these tools loses nothing in terms of Python's dynamism,
at least in theory.  In practice, if an EBNF grammar is difficult to
design, generating one dynamically might be even more difficult.  But
there is nothing in principle which stops you from creating grammars
on-the-fly, then compiling them (at runtime) into fast state-machines.

On a more general approach, Psyco magically speeds up a large class of
Python programs with next to no work.  Basically, you just add an import
and a 'psyco.jit()' to your program, and everything gets 5x faster.
That's very rough, a lot depends on what specific operations your
program performs; but it can be some very good mojo.

Yours, David...

--
    _/_/_/ THIS MESSAGE WAS BROUGHT TO YOU BY: Postmodern Enterprises _/_/_/
   _/_/    ~~~~~~~~~~~~~~~~~~~~[mertz at gnosis.cx]~~~~~~~~~~~~~~~~~~~~~  _/_/
  _/_/  The opinions expressed here must be those of my employer...   _/_/
 _/_/_/_/_/_/_/_/_/_/ Surely you don't think that *I* believe them!  _/_/