Regards,
Nick.

> Typically that also helps pypy so I'm not unbiased.
>
> Cheers,
> fijal
> _______________________________________________
> Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com

">

(original) (raw)


On 13 Feb 2013 07:08, "Maciej Fijalkowski" <fijall@gmail.com> wrote:
\>
\> Hi
\>
\> We recently encountered a performance issue in stdlib for pypy. It
\> turned out that someone commited a performance "fix" that uses += for
\> strings instead of "".join() that was there before.
\>
\> Now this hurts pypy (we can mitigate it to some degree though) and
\> possible Jython and IronPython too.
\>
\> How people feel about generally not having += on long strings in
\> stdlib (since the refcount = 1 thing is a hack)?
\>
\> What about other performance improvements in stdlib that are
\> problematic for pypy or others?
\>
\> Personally I would like cleaner code in stdlib vs speeding up CPython.

For the specific case of "Don't rely on the fragile refcounting hack in CPython's string concatenation" I strongly agree. However, as a general principle, I can't agree until speed.python.org is a going concern and we can get a reasonable overview of any resulting performance implications.

Regards,
Nick.

> Typically that also helps pypy so I'm not unbiased.
\>
\> Cheers,
\> fijal
\> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
\> Python-Dev mailing list
\> Python-Dev@python.org
\> http://mail.python.org/mailman/listinfo/python-dev
\> Unsubscribe: http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com