<p>Certain function calls can disable PyPy's speed options over
stretches of surrounding code called “JIT scopes”.</p>
<p>A JIT like PyPy's works based on the assumption that the only thing
worth optimizing are loops that are executed often. Whenever the
interpreter enters a loop in the interpreted program, the JIT records
what the interpreter does, creating a trace. This trace is optimized,
compiled to machine code and executed when the loop is hit with the
conditions observed during tracing. This trace is one kind of JIT scope.</p>
<p>Another kind of JIT scope that matters is a function, considered as
a unit for inlining.</p>
<p>Note that a JIT scope is a run-time phenomenon, not a compile-time
one. It's not confined by source-code module boundaries. A library-
or foreign-module call in a frequently-called loop or inlined function
will be part of its JIT scope.</p>
<p>locals(), globals(), sys._getframe(), sys.exc_info(), and sys.settrace
work in PyPy, but they incur a performance penalty that can be huge by
disabling the JIT over the enclosing JIT scope.</p>
<p>One unobvious case where frame introspection is used is the logging
module. Don't use the logging module if you need to run fast.</p>
<p><em>(Thanks Eric S. Raymond for the text above)</em></p>
</div>
</div>
<divclass="section"id="insider-s-point-of-view">
<h1><aclass="toc-backref"href="#id3">Insider's point of view</a></h1>
<p>This section describes performance issues from the point of view of
insiders of the project; it should be particularly interesting if you
plan to contribute in that area.</p>
<p>One of the goals of the PyPy project is to provide a fast and compliant
python interpreter. Some of the ways we achieve this are by providing a
high-performance garbage collector (GC) and a high-performance
...
...
@@ -116,12 +324,10 @@
<ttclass="docutils literal">reduce()</tt>, and to some extend <ttclass="docutils literal">map()</tt> (although the simple case
is JITted), and to all usages of the <ttclass="docutils literal">operator</tt> module we can think
of.</li>
<li><strong>Ctypes</strong>: Ctypes is a mixed bunch. If you're lucky you'll hit the
sweetspot and be <strong>really</strong> fast. If you're unlucky, you'll miss the
sweetspot and hit the slowpath which is much slower than CPython (2-10x
has been reported).</li>
<li><strong>Ctypes</strong>: Ctypes is slower than on CPython. Consider <aclass="reference external"href="http://cffi.readthedocs.org/">CFFI</a> instead,
which has special paths inside the JIT.</li>
</ul>
<p>We generally consider things that are slower on PyPy than CPython to be bugs
of PyPy. If you find some issue that is not documented here,
please report it to our <aclass="reference external"href="http://bugs.pypy.org">bug tracker</a> for investigation.</p>
</div>
...
...
@@ -123,8 +329,9 @@
</ul>
<p>We generally consider things that are slower on PyPy than CPython to be bugs
of PyPy. If you find some issue that is not documented here,
please report it to our <aclass="reference external"href="http://bugs.pypy.org">bug tracker</a> for investigation.</p>