[Lxml-checkins] r42849 - lxml/trunk/doc

[scoder at codespeak.net]

Author: scoder
Date: Tue May  8 14:20:12 2007
New Revision: 42849

Modified:
   lxml/trunk/doc/performance.txt
Log:
docs

Modified: lxml/trunk/doc/performance.txt
==============================================================================
--- lxml/trunk/doc/performance.txt	(original)
+++ lxml/trunk/doc/performance.txt	Tue May  8 14:20:12 2007
@@ -82,8 +82,8 @@
 overhead than the simpler top-down structure of ElementTree.  What this means
 is: the more of your code runs in Python, the less you can benefit from the
 speed of lxml and libxml2.  Note, however, that this is true for most
-performance critical Python applications.  No one would implement complex
-matrix calculations in pure Python when you can use NumPy.
+performance critical Python applications.  No one would implement fourier
+transformations in pure Python when you can use NumPy.
 
 The up side then is that lxml provides powerful tools like tree iterators,
 XPath and XSLT, that can handle complex operations at the speed of C.  Their
@@ -480,6 +480,11 @@
 
 So, what have we learned?
 
+* Python code is not slow.  The pure XPath solution was not even as fast as
+  the first shot Python implementation.  In general, a few more lines in
+  Python make things more readable, which is much more important than the last
+  5% of performance.
+
 * It's important to know the available options - and it's worth starting with
   the most simple one.  In this case, a programmer would then probably have
   started with ``getiterator("v")`` or ``iterparse()``.  Either of them would