[pypy-commit] pypy.org extradoc: Typo in capitalization. Regen.
arigo
noreply at buildbot.pypy.org
Mon Feb 13 10:33:58 CET 2012
Author: Armin Rigo <arigo at tunes.org>
Branch: extradoc
Changeset: r330:068ecf60cdf8
Date: 2012-02-13 10:33 +0100
http://bitbucket.org/pypy/pypy.org/changeset/068ecf60cdf8/
Log: Typo in capitalization. Regen.
diff --git a/performance.html b/performance.html
--- a/performance.html
+++ b/performance.html
@@ -99,10 +99,22 @@
might be worthwhile to consider rewriting it as a pure Python version
that uses something like <tt class="docutils literal">ctypes</tt> for the interface.</li>
<li><strong>Missing RPython modules</strong>: A few modules of the standard library
-(like <tt class="docutils literal">csv</tt> and <tt class="docutils literal">cPickle</tt>) are in C in CPython, but in pure Python
-in PyPy. Sometimes the JIT is able to do a good job on them, and
-sometimes not. In most cases (like <tt class="docutils literal">csv</tt> and <tt class="docutils literal">cPickle</tt>), we're slower
-than cPython, with the notable exception of <tt class="docutils literal">json</tt> and <tt class="docutils literal">heapq</tt>.</li>
+(like <tt class="docutils literal">csv</tt> and <tt class="docutils literal">cPickle</tt>) are written in C in CPython, but written
+natively in pure Python in PyPy. Sometimes the JIT is able to do a
+good job on them, and sometimes not. In most cases (like <tt class="docutils literal">csv</tt> and
+<tt class="docutils literal">cPickle</tt>), we're slower than CPython, with the notable exception of
+<tt class="docutils literal">json</tt> and <tt class="docutils literal">heapq</tt>.</li>
+<li><strong>Abuse of itertools</strong>: The itertools module is often “abused” in the
+sense that it is used for the wrong purposes. From our point of view,
+itertools is great if you have iterations over millions of items, but
+not for most other cases. It gives you 3 lines in functional style
+that replace 10 lines of Python loops (longer but arguably much easier
+to read). The pure Python version is generally not slower even on
+CPython, and on PyPy it allows the JIT to work much better – simple
+Python code is fast. The same argument also applies to <tt class="docutils literal">filter()</tt>,
+<tt class="docutils literal">reduce()</tt>, and to some extend <tt class="docutils literal">map()</tt> (although the simple case
+is JITted), and to all usages of the <tt class="docutils literal">operator</tt> module we can think
+of.</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,
diff --git a/source/performance.txt b/source/performance.txt
--- a/source/performance.txt
+++ b/source/performance.txt
@@ -66,7 +66,7 @@
(like ``csv`` and ``cPickle``) are written in C in CPython, but written
natively in pure Python in PyPy. Sometimes the JIT is able to do a
good job on them, and sometimes not. In most cases (like ``csv`` and
- ``cPickle``), we're slower than cPython, with the notable exception of
+ ``cPickle``), we're slower than CPython, with the notable exception of
``json`` and ``heapq``.
* **Abuse of itertools**: The itertools module is often "abused" in the
More information about the pypy-commit
mailing list