Python execution speed

[Steve Holden]

"Peter Hansen" <peter at engcorp.com> wrote in message
news:3BFC92FC.FEEC75BF at engcorp.com...
> 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.
>
Aa, yes, the good old 80/20 rule strikes again.

> 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).
>
It's surprising how often the question "How fast is fast enough" isn't asked
in advance of a project's testing stages. Clearly there are some areas
(scientific computing, image analysis) that do benefit from liberal
applications of C, but Python tends to be used as a glue language in these
contexts.

> 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.
>
Correct.

> 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".
>
Indeed. My own experience with Python (though I don't do any scientific
computing, and not much with images either) is that it goes fast enough. In
areas where it doesn't go fast enough, using Python plus C modules is still
quicker (I believe) than writing the whole project in C from the start.

> (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...
>
My ancient hardware still drives Python fast enough for my purposes. When it
doesn't, I'll use that as an excuse to upgrade the old stuff, not winge
about the expense of writing in C <0.8 wink>. I'm looking forward to my
1.7GHz laptop...

old-codgers-have-to-stick-together-ly y'rs  - steve
--
http://www.holdenweb.com/