[pypy-commit] extradoc extradoc: try to explain that PyPy's approach to GC is better than reference counting. A lot of people are surprised to read that generational GC is faster than refcount

[antocuni]

Author: Antonio Cuni <anto.cuni at gmail.com>
Branch: extradoc
Changeset: r5081:6b5bf67ab352
Date: 2013-10-15 11:22 +0200
http://bitbucket.org/pypy/extradoc/changeset/6b5bf67ab352/

Log:	try to explain that PyPy's approach to GC is better than reference
	counting. A lot of people are surprised to read that generational GC
	is faster than refcount

diff --git a/blog/draft/incremental-gc.rst b/blog/draft/incremental-gc.rst
--- a/blog/draft/incremental-gc.rst
+++ b/blog/draft/incremental-gc.rst
@@ -34,8 +34,13 @@
 
 PyPy essentially has only the cycle finder - it does not bother with reference
 counting, instead it walks alive objects every now and then (this is a big
-simplification, PyPy's GC is much more complex than this). As a result it also
-has the problem of GC pauses. To alleviate this problem, which is essential for
+simplification, PyPy's GC is much more complex than this). Although this might
+sound like a missing feature, it is really one of the reasons why PyPy is so
+fast, because at the end of the day the total time spent in managing the
+memory is lower in PyPy than CPython. However, as a result, PyPy also has the
+problem of GC pauses.
+
+To alleviate this problem, which is essential for
 applications like games, we started to work on incremental GC, which spreads
 the walking of objects and cleaning them across the execution time in smaller
 intervals. The work was sponsored by the Raspberry Pi foundation, started