Python and STL efficiency

[Tim N. van der Leeuw]

skip at pobox.com wrote:
> Tim> But beware! For Python2.5 I had to change the code slightly,
>     Tim> because it already realized that the expression
>
>     Tim> '%s' % 'something'
>
>     Tim> will be a constant expression, and evaluates it once only... so I
>     Tim> had to replace '%s' with a variable, and I got the timings above
>     Tim> which show Python2.5 to be slightly faster than Python2.4.
>
> Shouldn't you then get rid of any compiler optimizations your C++ compiler
> does?  Why penalize 2.5 because it recognizes a useful optimization?
>
The point is that I was trying to create 400.000 string instances. The
extra optimization in 2.5 required an extra trick for that.
The idea is to compare a C++ version which creates 400.000 string
instances, with a Python version which creates 400.000 string
instances; then reduce those 400.000 instances to a set of only 4
unique strings.
(So I cannot just create a list with strings generated from numbers 1 -
400.000, and I didn't want to change the original code too much, so I
just added a trick to make Python allocate a new string each time
round.)

I agree that Python2.5 recognized a useful optimization, and didn't
wish to penalize it for that, however the optimalization was defeating
the purpose of my code in the first place!

Cheers,

--Tim