Incorporate measurement results.
This commit is contained in:
parent
ec36aa4fa8
commit
bb0d67250e
21
pep-0393.txt
21
pep-0393.txt
|
@ -372,6 +372,25 @@ the iobench, stringbench, and json benchmarks see typically
|
|||
slowdowns of 1% to 30%; for specific benchmarks, speedups may
|
||||
happen as may happen significantly larger slowdowns.
|
||||
|
||||
In actual measurements of a Django application ([2]_), significant
|
||||
reductions of memory usage could be found. For example, the storage
|
||||
for Unicode objects reduced to 2216807 bytes, down from 6378540 bytes
|
||||
for a wide Unicode build, and down from 3694694 bytes for a narrow
|
||||
Unicode build (all on a 32-bit system). This reduction came from the
|
||||
prevalence of ASCII strings in this application; out of 36,000 strings
|
||||
(with 1,310,000 chars), 35713 where ASCII strings (with 1,300,000
|
||||
chars). The sources for these strings where not further analysed;
|
||||
many of them likely originate from identifiers in the library, and
|
||||
string constants in Django's source code.
|
||||
|
||||
In comparison to Python 2, both Unicode and byte strings need to be
|
||||
accounted. In the test application, Unicode and byte strings combined
|
||||
had a length of 2,046,000 units (bytes/chars) in 2.x, and 2,200,000
|
||||
units in 3.x. On a 32-bit system, where the 2.x build used 32-bit
|
||||
wchar_t/Py_UNICODE, the 2.x test used 3,620,000 bytes, and the 3.x
|
||||
build 3,340,000 bytes. This reduction in 3.x using the PEP compared
|
||||
to 2.x only occurs when comparing with a wide unicode build.
|
||||
|
||||
Porting Guidelines
|
||||
==================
|
||||
|
||||
|
@ -435,6 +454,8 @@ References
|
|||
|
||||
.. [1] PEP 393 branch
|
||||
https://bitbucket.org/t0rsten/pep-393
|
||||
.. [2] Django measurement results
|
||||
http://www.dcl.hpi.uni-potsdam.de/home/loewis/djmemprof/
|
||||
|
||||
Copyright
|
||||
=========
|
||||
|
|
Loading…
Reference in New Issue