Python execution speed

[Peter Hansen]

Chris Barker wrote:
> 
> Peter Hansen wrote:
> > The usual approach is simply to profile the
> > code and recode the "hot spot" in C.
> 
> This is a problem, not a solution! Most of the code I write is in Python
> and it is "fast enough", but not all. And while I end up having to write
> only little bits in C, those little bits take me a whole lot longer than
> a large bits of Python code. 

I still see it as a solution, but obviously that's a personal 
opinion (which, as the "customer", I then impose on the team :-).
I consider 95% of all optimization that programmers do to be
entirely unnecessary, amounting to nothing more than "faster"
and for no other reason than "we need it faster" (which is
usually not true).

The only acceptable reason for optimization (in this view)
is "our customer requires response time of X and we are 
running at Y" (where Y is slower than X).  The only acceptable
amount of optimization is up to the point where Y equals X.

So far, other than casual improvements as we refactor the
code for other reasons, we have not in two years of use
of Python actually *needed* to optimize anything.  I can
readily dissuade anyone in our group from trying very hard
to optimize by pointing out that their best efforts would 
produce only a tiny fraction of the speedup we would see by 
using C.  The fact that rewriting in C is non-trivial just 
serves to keep us focused back on functionality that *is*
required by the customer, rather than constantly answering 
the siren song of "faster, faster".

(Yes, obviously a somewhat obtuse attitude, and no doubt
we're not quite that extreme, but I think it makes the
point.)

But then again, I'm still using a Pentium 233 MMX which
is lots fast enough for home use.  Those with PCs slower
than this might have more credibility arguing for 
speed-ups in Python than those with the latest 2GHz
chips...

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