Path: csiph.com!usenet.pasdenom.info!news.albasani.net!newsfeed.freenet.ag!news2.euro.net!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <51411F38.1040901@mrabarnett.plus.com>
References: <23a42297-9262-4ace-87ad-138999b1ddd6@z3g2000vbg.googlegroups.com> <a1a6394a-e9c7-407b-9f6d-ff44de1b65de@y2g2000pbg.googlegroups.com> <eabe27a9-099a-4e2c-92fb-bdf3819c2561@kw7g2000pbb.googlegroups.com> <mailman.3259.1363172350.2939.python-list@python.org> <ee2062d1-658a-4bf5-8a56-5fe9c0991bef@o9g2000pbt.googlegroups.com> <CAPTjJmqEAdff+cH2NWtp0oX1ZvFzQJqPxNm=c8=XAm3j+GV1uQ@mail.gmail.com> <51411F38.1040901@mrabarnett.plus.com>
Date: Thu, 14 Mar 2013 11:55:47 +1100
Subject: Re: String performance regression from python 3.2 to 3.3
From: Chris Angelico <rosuav@gmail.com>
To: python-list@python.org
Content-Type: text/plain; charset=ISO-8859-1
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.3281.1363222550.2939.python-list@python.org>
Lines: 53
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:41204

On Thu, Mar 14, 2013 at 11:52 AM, MRAB <python@mrabarnett.plus.com> wrote:
> On 13/03/2013 23:43, Chris Angelico wrote:
>>
>> On Thu, Mar 14, 2013 at 3:49 AM, rusi <rustompmody@gmail.com> wrote:
>>>
>>> On Mar 13, 3:59 pm, Chris Angelico <ros...@gmail.com> wrote:
>>>>
>>>> On Wed, Mar 13, 2013 at 9:11 PM, rusi <rustompm...@gmail.com> wrote:
>>>> > Uhhh..
>>>> > Making the subject line useful for all readers
>>>>
>>>> I should have read this one before replying in the other thread.
>>>>
>>>> jmf, I'd like to see evidence that there has been a performance
>>>> regression compared against a wide build of Python 3.2. You still have
>>>> never answered this fundamental, that the narrow builds of Python are
>>>> *BUGGY* in the same way that JavaScript/ECMAScript is. And believe you
>>>> me, the utterly unnecessary hassles I have had to deal with when
>>>> permitting user-provided .js code to script my engine have wasted
>>>> rather more dev hours than you would believe - there are rather a lot
>>>> of stupid edge cases to deal with.
>>>
>>>
>>> This assumes that there are only three choices:
>>> - narrow build that is buggy (surrogate pairs for astral characters)
>>> - wide build that is 4-fold space inefficient for wide variety of
>>> common (ASCII) use-cases
>>> - flexible string engine that chooses a small tradeoff of space
>>> efficiency over time efficiency.
>>>
>>> There is a fourth choice: narrow build that chooses to be partial over
>>> being buggy. ie when an astral character is encountered, an exception
>>> is thrown rather than trying to fudge it into a 16-bit
>>> representation.
>>
>>
>> As a simple factual matter, narrow builds of Python 3.2 don't do that.
>> So it doesn't factor into my original statement. But if you're talking
>> about a proposal for 3.4, then sure, that's a theoretical possibility.
>> It wouldn't be "buggy" in the sense of "string indexing/slicing
>> unexpectedly does the wrong thing", but it would still be incomplete
>> Unicode support, and I don't think people would appreciate it. Much
>> better to have graceful degradation: if there are non-BMP characters
>> in the string, then instead of throwing an exception, it just makes
>> the string wider.
>>
> [snip]
> Do you mean that instead of switching between 1/2/4 bytes per codepoint
> it would switch between 2/4 bytes per codepoint?

That's my point. We already have the better version. :)

ChrisA