A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2004-June/045667.html below:

[Python-Dev] Wild Idea for the Year

[Python-Dev] Wild Idea for the Year [Python-Dev] Wild Idea for the YearPhillip J. Eby pje at telecommunity.com
Sun Jun 27 18:03:06 EDT 2004
At 02:38 PM 6/27/04 +0100, Armin Rigo wrote:
>Hello,
>
>On Sat, Jun 19, 2004 at 03:40:07PM -0400, Raymond Hettinger wrote:
> >         s = ""
> >         for e in iterable:
> >             s = s + e
>
>Hum, it may not be impossible after all.
>
>http://www.python.org/sf/980695 -> an idea that seems to work and only
>involves 3 pages of obfuscated code in new well-isolated functions of 
>ceval.c.
>stringobject.c is unmodified.

Looks interesting.  It appears the cost is added to cases that are likely 
to have longer execution times anyway.  (i.e. the slow_add and slow_iadd 
cases.)

I notice that string_concatenate() doesn't cover the STORE_DEREF case, 
however.  Was that intentional?

Last question: is this actually faster when 'e' is replaced by an 
expression that causes memory allocation?  That is, isn't this *still* 
going to be an O(n**2) operation if the string has to be relocated on each 
addition?


More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4