Larry Hastings wrote:Chetan Pandya wrote:> I don't have a patch build, since I didn't download the revision used
> by the patch.> However, I did look at values in the debugger and it looked like x in> your example above had a reference count of 2 or more within> string_concat even when there were n
+ for string Re:PATCHsubmitted: Speed up + for string concatenation, now as fast as
"".join(x) idiomTo: python-dev@python.orgMessage-ID: <[EMAIL PROTECTED]>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Chetan Pandya wrote:> The deallocation code
My statement wasn't clear enough.Rendering occurs if the string being concatenated is already a concatenation object created by an earlier assignment. In s = a + b + c + d + e + f , there would be rendering of the source string if it is already a concatenation.
Here is an example that would make it
The discussion on this topic seems to have died down. However, I had a look at the patch and here are some comments:This has the potential to speed up simple strings expressions likes = '1' + '2' + '3' + '4' + '5' + '6' + '7' + '8'
However, if this is followed bys += '9' this (the 9th string) will
I just got around to reading the messages.When I first saw this, I thought this is so that the processes that need to share and work on shared objects. That is where the locks are required. However, all shread objects are managed by the object manager and thus all such operations are in effect sequ