YATOPS (Yet Another Thread on Python's Speed)

Greg Stein gstein at lyra.org
Mon Jan 6 20:26:47 EST 2003


In article <3E144BFC.399B8510 at engcorp.com>, "Peter Hansen"
<peter at engcorp.com> wrote:
>...
> ** "too slow" is almost always defined incorrectly.  In most cases, it
> means "I think this should run faster".  In fact, it should be defined
> as "my customers *require* that this run faster" or something more like
> that.  Most developers are wrong about how fast things really need to
> run... (maybe because they have no requirements.)

Oh, hell ya. I ran into that a bunch when my company (eShop) was acquired
and we arrived at Microsoft with a bunch of Python code in hand. "We have
to rewrite it in C! It's too slow!" "Really? How fast should it be?"
"Um...."

Of course, they still ended up rewriting it...
(but in all fairness, it was probably better as it increased the number
of developers who could actually work on the code and maintain it)

> Another key point is that most people start to optimize their code
> *without* having profiled it first, and *without* making sure the code
> is actually working properly first (i.e. "finished") . Optimization
> without profiling is always bad and, to quote Knuth yet again,
> "Premature optimization is the root of all evil."

The quote I always use is: 90% of the time, you're wrong about where you
spend 90% of the time.

In the case of the eShop code, we were mostly network and database bound.
Changing the stuff in between would do very, very little. And even then,
the bulk of what it *did* do was template processing. And that was all
Python string handling, which was in C anyways!

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/






More information about the Python-list mailing list