[Python-Dev] PEP 393 review

Thu Aug 25 13:27:34 CEST 2011

Hello,
On 2011年8月25日 10:24:39 +0200
"Martin v. Löwis" <martin at v.loewis.de> wrote:
>> On a 32-bit machine with a 32-bit wchar_t, pure-ASCII strings of length
> 1 (+NUL) will take the same memory either way: 8 bytes for the
> characters in 3.2, 2 bytes in 3.3 + extra pointer + padding. Strings
> of 2 or more characters will take more space in 3.2.
>> On a 32-bit machine with a 16-bit wchar_t, pure-ASCII strings up
> to 3 characters take the same space either way; space savings start at
> four characters.
>> On a 64-bit machine with a 16-bit wchar_t, assuming a malloc minimum
> block size of 16 bytes, pure-ASCII strings of up to 7 characters take
> the same space. For 8 characters, 3.2 will need 32 bytes for the
> characters, whereas 3.3 will only take 16 bytes (due to padding).

That's very good. For future reference, could you add this information
to the PEP?
> >> - conditions you would like to pose on the implementation before
> >> acceptance. I'll see which of these can be resolved, and list
> >> the ones that remain open.
> > 
> > That it doesn't significantly slow down benchmarks such as stringbench
> > and iobench.
>> Can you please quantify "significantly"? Also, having a complete list
> of benchmarks to perform prior to acceptance would be helpful.

I would say no more than a 15% slowdown on each of the following
benchmarks:
- stringbench.py -u
 (http://svn.python.org/view/sandbox/trunk/stringbench/)
- iobench.py -t
 (in Tools/iobench/)
- the json_dump, json_load and regex_v8 tests from
 http://hg.python.org/benchmarks/
I believe these are representative of string-heavy operations.
Additionally, it would be nice if you could run at least some of the
test_bigmem tests, according to your system's available RAM.
Regards
Antoine.