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

[Sam Penrose]

A recent article in this forum linked to an analysis of the
performance of several popular languages, including Python.
The article finds that instantiating an object in Python is
a particularly expensive operation relative both to other
Python operations and to instantiating an object in other
languages. My experience is that moving c. 1000 lines of 
CPython code from a relatively procedural to a relatively
object-oriented approach incurs a definite performance hit
on vintage 1998 Intel hardware running Linux (Python 1.5.2).

1) Does informed opinion agree that object instantiation is
noticeably performance-expensive in CPython? (Unfortunately,
I can't seem to find the article in question.)

2) If so, does Python 1.6 address this issue? Will later versions?

Note: I thoroughly agree with Thomas' comments on the virtues
of what he calls the Python Way.


In article <20000617120003.S26436 at xs4all.nl>, Thomas Wouters 
<thomas at xs4all.net> wrote:

<snip>
> You can probably speed up Python quite a bit if you concentrate
> on the common task and do not mind fawlty or flawed 
> results for the little used features.
> 
> Fortunately (in my opinion), that isn't the Python Way. 
> There is still room for improvement without losing accuracy
> and simplicity (of Python) but that *will* cost, in 
> simplicity-of-CPython: The current optimization (which
> translates 'load_name' opcodes into 'load_global' or 'load_fast'
> depending on wether they seem to be local or global) is a good
> example: The actual added code is not that large or complicated,
> but when you start adding new features, you have to keep those
> 20-odd lines of code in mind, or you'll screw it up. Add 10 more
> of those 'performance hacks' and adding to CPython can become a
> real pain.
> 
> Also, the load_fast-translation-cycle is skipped if the code block has a
> 'from module import *' or 'exec' statement in it, because the
> compiler/optimizer does not know what names it imports, and hence not 
> what names will be actually local when the code executes.
> 
> Optimized-Python-contradicts-'simplicitly'-both-ways-ly y'rs,