[pypy-svn] r20670 - pypy/dist/pypy/doc

arigo at codespeak.net arigo at codespeak.net
Mon Dec 5 12:54:24 CET 2005


Author: arigo
Date: Mon Dec  5 12:54:22 2005
New Revision: 20670

Modified:
   pypy/dist/pypy/doc/low-level-encapsulation.txt
Log:
Minor tweaks in Experimental Results.


Modified: pypy/dist/pypy/doc/low-level-encapsulation.txt
==============================================================================
--- pypy/dist/pypy/doc/low-level-encapsulation.txt	(original)
+++ pypy/dist/pypy/doc/low-level-encapsulation.txt	Mon Dec  5 12:54:22 2005
@@ -245,19 +245,21 @@
 
 Stacklessness
 
-    Producing Stackless-style C code currently means that all the
-    functions of the PyPy interpreter use the new style.  The current
-    performance impact is to make PyPy slower by about 10%.  A couple of
-    minor pending optimisations could reduce this figure a bit.  We
-    expect the rest of the performance impact to be mainly caused by the
-    increase of size of the generated executable (+20%).
+    Producing Stackless-style C code means that all the functions of the
+    PyPy interpreter that can be involved in recursions contain stack
+    bookkeeping code (leaf functions, functions calling only leaves,
+    etc. do not need to use this style).  The current performance impact
+    is to make PyPy slower by about 10%.  A couple of minor pending
+    optimisations could reduce this figure a bit.  We expect the rest of
+    the performance impact to be mainly caused by the increase of size
+    of the generated executable (+20%).
 
 Multiple Interpreters
 
     A binary that allowed selection between two copies of the standard
     object space with a command line switch was about 10% slower and
     about 40% larger than the default.  Most of the extra size is
-    likely accounted for by the duplication of the large amount
+    likely accounted for by the duplication of the large amount of
     prebuilt data involved in an instance of the standard object
     space.
 
@@ -267,7 +269,7 @@
     comparison, using reference counting instead makes the interpreter
     twice as slow.  This is almost certainly due to the naive approach
     to reference counting used so far, which updates the counter far
-    more often than theoretically necessary; we also still have a lot of
+    more often than strictly necessary; we also still have a lot of
     objects that would theoretically not need a reference counter,
     either because they are short-lived or because we can prove that
     they are "owned" by another object and can share its lifetime.  In



More information about the Pypy-commit mailing list