Possible memory leak?

[Steven D'Aprano]

Giovanni Bajo wrote:

> Steven D'Aprano wrote:
> 
> 
>>But the real killer is this one line:
>>
>>row=row+chr(num/64)
>>
>>Bad, bad BAD idea. Every time you add two strings together, Python
>>has to copy BOTH strings. As row gets huge, this takes longer and
>>longer to do.
> 
> 
> This is no longer true as of CPython 2.4 though. I'm not sure which version the
> OP was using because he didn't say.

No, that's not correct. You are making a false 
assumption. This is from the "What's New" for Python 2.4:

[quote]
String concatenations in statements of the form s = s + 
"abc" and s += "abc" are now performed more efficiently 
in certain circumstances. This optimization won't be 
present in other Python implementations such as Jython, 
so you shouldn't rely on it; using the join() method of 
strings is still recommended when you want to 
efficiently glue a large number of strings together.
[end quote]

Note the "more efficiently in CERTAIN CIRCUMSTANCES" 
[emphasis added]? That certainly does not mean that 
concatenating large numbers of strings is no longer 
slow. It just means that *sometimes* (almost always? 
often? occasionally?) it isn't as slow as it used to be.

We really don't know what the optimization recognises, 
how it works, or how fast a difference it makes. 
Writing poor code, and trusting an implementation-
specific optimization to make it run "faster" (how much 
faster?) is always a dangerous strategy.

Better to avoid the temptation if you can, appreciate 
the improved performance for those times when you do 
string concatenation, but continue to use the join 
method anytime you are adding large numbers of strings.


-- 
Steven.