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

[scoder at codespeak.net]

Author: scoder
Date: Wed May  9 00:08:42 2007
New Revision: 42886

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

Modified: lxml/trunk/doc/performance.txt
==============================================================================
--- lxml/trunk/doc/performance.txt	(original)
+++ lxml/trunk/doc/performance.txt	Wed May  9 00:08:42 2007
@@ -27,6 +27,25 @@
    7  lxml.objectify
 
 
+General notes
+=============
+
+First thing to say: there *is* an overhead involved in having a DOM-like C
+library mimic the ElementTree API.  As opposed to ElementTree, lxml has to
+generate Python representations of tree nodes on the fly when asked for them,
+and the internal tree structure of libxml2 results in a higher maintenance
+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 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
+pythonic API in lxml makes them so flexible that most applications can easily
+benefit from them.
+
+
 How to read the timings
 =======================
 
@@ -73,25 +92,6 @@
 compare.
 
 
-General notes
-=============
-
-First thing to say: there *is* an overhead involved in having a DOM-like C
-library mimic the ElementTree API.  As opposed to ElementTree, lxml has to
-generate Python representations of tree nodes on the fly when asked for them,
-and the internal tree structure of libxml2 results in a higher maintenance
-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 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
-pythonic API in lxml makes them so flexible that most applications can easily
-benefit from them.
-
-
 Parsing and Serialising
 =======================