Possible memory leak?

[Fredrik Lundh]

Steven D'Aprano 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.

it only means that if the interpreter can make sure that else is
using the target string, it's modified in place.

however, the string type doesn't use overallocation (beyond the
8-byte alignment provided by the memory allocator), so this fix
only avoids extra copying in a few specific cases.  O(n*n/8) is
still quadratic...

</F>