Author: Armin Rigo <ar...@tunes.org> Branch: Changeset: r72319:787e204c5c92 Date: 2014-07-02 20:10 +0200 http://bitbucket.org/pypy/pypy/changeset/787e204c5c92/
Log: Update: now stm is 'only' 2x slower rather than 10x on translate.py. diff --git a/pypy/doc/stm.rst b/pypy/doc/stm.rst --- a/pypy/doc/stm.rst +++ b/pypy/doc/stm.rst @@ -92,9 +92,9 @@ We're busy fixing them as we find them; feel free to `report bugs`_. * It runs with an overhead as low as 20% on examples like "richards". - There are also other examples with higher overheads --up to 10x for - "translate.py"-- which we are still trying to understand. One suspect - is our partial GC implementation, see below. + There are also other examples with higher overheads --currently up to + 2x for "translate.py"-- which we are still trying to understand. + One suspect is our partial GC implementation, see below. * Currently limited to 1.5 GB of RAM (this is just a parameter in `core.h`__). Memory overflows are not correctly handled; they cause @@ -111,9 +111,8 @@ * The GC is new; although clearly inspired by PyPy's regular GC, it misses a number of optimizations for now. Programs allocating large - numbers of small objects that don't immediately die, as well as - programs that modify large lists or dicts, suffer from these missing - optimizations. + numbers of small objects that don't immediately die (surely a common + situation) suffer from these missing optimizations. * The GC has no support for destructors: the ``__del__`` method is never called (including on file objects, which won't be closed for you). _______________________________________________ pypy-commit mailing list pypy-commit@python.org https://mail.python.org/mailman/listinfo/pypy-commit
