Optimizing Object Instantiation (was Re: How Fast Does Python Run?)

Mark Hammond mhammond at skippinet.com.au
Sun Jun 18 20:30:42 EDT 2000


"Sam Penrose" <see at message.body> wrote in message
news:see-262267.15582418062000 at news.dnai.com...

> The code in question is based around nested __init__ calls:
> a main working class which is based on an abstract class
> (2 __inits__) and which calls a wrapper class (3) around the
> MySQLdb module (4).
>
> I'm starting to think for other reasons that I've been
> overcoding, but it would be nice to know whether the
> performance issue has any prospects of being addressed.

Not really!  The problem is simply that you execute a fair bit of Python
code, including a number of function calls (which are expensive) for each
object instantiation.

So, while we all try very hard to optimize Python, the fact remains that
you are running this code for each object, and it can never be faster than
the Python interpreter can chew through it.

Use the standard Python profiler - this should help you identify how you
can make the code that must execute as fast as possible - then you can
decide an appropriate strategy.

> OTOH, it's amazing how much faster $2,500 worth of current
> hardware is than the system we spent $2,500 on two years ago;
> perhaps the point will prove moot.

Too true - but the problem is Python is _too_ quick to develop - by the
time your app is finished, speeds havent moved too much.  OTOH, choosing
something like C++ often means the project takes far far longer, meaning
you do indeed see hardware speeds improve over the life of the project.
So ironically, it seems that you get the hardware speed increase for
"free" when using the languages that need it least :-)

Mark.





More information about the Python-list mailing list