# HG changeset patch
# User Armin Rigo <arigo@tunes.org>
# Date 1329125624 -3600
#      Mon Feb 13 10:33:44 2012 +0100
# Branch extradoc
# Node ID 068ecf60cdf86da4c4e148e7ae4b54a6dbb3f76a
# Parent  656ba44c4a506b9396fd256e4318a0c77a84e9ab
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 &ldquo;abused&rdquo; 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 &ndash; 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