Author: Alex Gaynor <alex.gay...@gmail.com> Branch: extradoc Changeset: r5103:b710505c06d1 Date: 2013-10-25 16:25 -0700 http://bitbucket.org/pypy/extradoc/changeset/b710505c06d1/
Log: rewrite diff --git a/blog/draft/coverage.rst b/blog/draft/coverage.rst --- a/blog/draft/coverage.rst +++ b/blog/draft/coverage.rst @@ -55,13 +55,13 @@ it did it in a particularly insidious way — the JIT had no idea it was being disabled! -Instead, every time PyPy discovered one of your functions was a hotspot, it -would start tracing, to observe what the program was doing, and right when it -was about to finish, ``coverage`` would run, and it would cause the JIT to -abort. Tracing is a slow process, it makes up for it by generating fast machine -code at the end, but tracing is still incredibly slow. But we never actually -got to the "generate fast machine code" stage. Instead we'd pay all the cost of -tracing, but then we'd abort, and reap none of the benefits. +Instead, every time PyPy discovered that one of your functions was a hotspot, +it would start tracing to observe what the program was doing, and right when it +was about to finish, ``coverage`` would run and cause the JIT to abort. Tracing +is a slow process, it makes up for it by generating fast machine code at the +end, but tracing is still incredibly slow. But we never actually got to the +"generate fast machine code" stage. Instead we'd pay all the cost of tracing, +but then we'd abort, and reap none of the benefits. To fix this, we adjusted some of the heuristics in the JIT, to better show it how ``sys.settrace()`` works. Previously the JIT saw "here's an opaque function _______________________________________________ pypy-commit mailing list pypy-commit@python.org https://mail.python.org/mailman/listinfo/pypy-commit
