From: Antoine Pitrou Date: Thu, 17 Nov 2011 00:59:51 +0000 (+0100) Subject: Explain concrete (resource consumption) effects of PEP 393 a bit. X-Git-Tag: v3.3.0a1~820 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=beb7836260127be0723b4aabdf6a667fe620119a;p=python Explain concrete (resource consumption) effects of PEP 393 a bit. --- diff --git a/Doc/whatsnew/3.3.rst b/Doc/whatsnew/3.3.rst index 6a31fa3ad7..8b91a0006c 100644 --- a/Doc/whatsnew/3.3.rst +++ b/Doc/whatsnew/3.3.rst @@ -84,11 +84,19 @@ Changes introduced by :pep:`393` are the following: * non-BMP strings (``U+10000-U+10FFFF``) use 4 bytes per codepoint. -.. The memory usage of Python 3.3 is two to three times smaller than Python 3.2, - and a little bit better than Python 2.7, on a `Django benchmark - `_. - XXX The result should be moved in the PEP and a small summary about - performances and a link to the PEP should be added here. + The net effect is that for most applications, memory usage of string storage + should decrease significantly - especially compared to former wide unicode + builds - as, in many cases, strings will be pure ASCII even in international + contexts (because many strings store non-human language data, such as XML + fragments, HTTP headers, JSON-encoded data, etc.). We also hope that it + will, for the same reasons, increase CPU cache efficiency on non-trivial + applications. + + .. The memory usage of Python 3.3 is two to three times smaller than Python 3.2, + and a little bit better than Python 2.7, on a `Django benchmark + `_. + XXX The result should be moved in the PEP and a link to the PEP should + be added here. * With the death of narrow builds, the problems specific to narrow builds have also been fixed, for example: