[Python-Dev] PATCH submitted: Speed up + for string concatenation, now as fast as "".join(x) idiom

[Nicko van Someren]

On 6 Oct 2006, at 12:37, Ron Adam wrote:

>>> I've never liked the "".join([]) idiom for string concatenation;  
>>> in my
>>> opinion it violates the principles "Beautiful is better than  
>>> ugly." and
>>> "There should be one-- and preferably only one --obvious way to  
>>> do it.".
...
> Well I always like things to run faster, but I disagree that this  
> idiom is broken.
>
> I like using lists to store sub strings and I think it's just a  
> matter of
> changing your frame of reference in how you think about them.

I think that you've hit on exactly the reason why this patch is a  
good idea.  You happen to like to store strings in lists, and in many  
situations this is a fine thing to do, but if one is forced to change  
ones frame of reference in order to get decent performance then as  
well as violating the maxims Larry originally cited you're also  
hitting both "readability counts" and "Correctness and clarity before  
speed."

The "".join(L) idiom is not "broken" in the sense that, to the fluent  
Python programmer, it does convey the intent as well as the action.   
That said, there are plenty of places that you'll see it not being  
used because it fails to convey the intent.  It's pretty rare to see  
someone write:
     for k,v in d.items():
         print " has value: ".join([k,v])
but, despite the utility of the % operator on strings it's pretty  
common to see:
         print k + " has value: " + v

This patch _seems_ to be able to provide better performance for this  
sort of usage and provide a major speed-up for some other common  
usage forms without causing the programmer to resort making their  
code more complicated.  The cost seems to be a small memory hit on  
the size of a string object, a tiny increase in code size and some  
well isolated, under-the-hood complexity.

It's not like having this patch is going to force anyone to change  
the way they write their code.  As far as I can tell it simply offers  
better performance if you choose to express your code in some common  
ways.  If it speeds up pystone by 5.5% with such minimal down side  
I'm hard pressed to see a reason not to use it.

Cheers,
	Nicko