Hello, On Thu, 25 Aug 2011 10:24:39 +0200 "Martin v. Löwis" <mar...@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. _______________________________________________ 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/archive%40mail-archive.com
