XML parser performance in PyPy

Juni 25th, 2012

I recently showed some benchmark results comparing the XML parser performance in CPython 3.3 to that in PyPy 1.7. Here’s an update for PyPy 1.9 that also includes the current state of the lxml port to that platform, parsing a 3.4MB document style XML file.

CPython 3.3pre:

Initial Memory usage: 11332
xml.etree.ElementTree.parse done in 0.041 seconds
Memory usage: 21468 (+10136)
xml.etree.cElementTree.parse done in 0.041 seconds
Memory usage: 21464 (+10132)
xml.etree.cElementTree.XMLParser.feed(): 25317 nodes read in 0.041 seconds
Memory usage: 21736 (+10404)
lxml.etree.parse done in 0.032 seconds
Memory usage: 28324 (+16992)
drop_whitespace.parse done in 0.030 seconds
Memory usage: 25172 (+13840)
lxml.etree.XMLParser.feed(): 25317 nodes read in 0.037 seconds
Memory usage: 30608 (+19276)
minidom tree read in 0.492 seconds
Memory usage: 29852 (+18520)

PyPy without JIT warming:

Initial Memory usage: 42156
xml.etree.ElementTree.parse done in 0.452 seconds
Memory usage: 44084 (+1928)
xml.etree.cElementTree.parse done in 0.450 seconds
Memory usage: 44080 (+1924)
xml.etree.cElementTree.XMLParser.feed(): 25317 nodes read in 0.457 seconds
Memory usage: 47920 (+5768)
lxml.etree.parse done in 0.033 seconds
Memory usage: 58688 (+16536)
drop_whitespace.parse done in 0.033 seconds
Memory usage: 55536 (+13384)
lxml.etree.XMLParser.feed(): 25317 nodes read in 0.055 seconds
Memory usage: 64724 (+22564)
minidom tree read in 0.541 seconds
Memory usage: 59456 (+17296)

PyPy with JIT warmup:

Initial Memory usage: 646824
xml.etree.ElementTree.parse done in 0.341 seconds
xml.etree.cElementTree.parse done in 0.345 seconds
xml.etree.cElementTree.XMLParser.feed(): 25317 nodes read in 0.342 seconds
lxml.etree.parse done in 0.026 seconds
drop_whitespace.parse done in 0.025 seconds
lxml.etree.XMLParser.feed(): 25317 nodes read in 0.039 seconds
minidom tree read in 0.383 seconds

What you can quickly see is that lxml performs equally well on both (actually slightly faster on PyPy) and beats the other libraries on PyPy by more than an order of magnitude. The absolute numbers are fairly low, though, way below a second for the 3.4MB file. It’ll be interesting to see some more complete benchmarks at some point that also take some realistic processing into account.

Remark: cElementTree is just an alias for the plain Python ElementTree on PyPy and ElementTree uses cElementTree in the background in CPython 3.3, which is why both show the same performance. The memory sizes were measured in forked processes, whereas the PyPy JIT numbers were measured in a repeatedly running process in order to take advantage of the JIT compiler. Note the substantially higher memory load of PyPy here.

Update: I originally reported the forked memory size with the non-forked performance for PyPy. The above now shows both separately. A more real-world comparison would likely yield an even higher memory usage on PyPy than the numbers above, which were mostly meant to give an idea of the memory usage of the in-memory tree (i.e. the data impact).

top of the list

April 3rd, 2012

lxml is top of the list for Python 3 downloads from PyPI!

lxml is top of the list!

XML parser performance in CPython 3.3 and PyPy 1.7

Dezember 16th, 2011

In a recent article, I compared the performance of MiniDOM and the three ElementTree implementations ElementTree, cElementTree and lxml.etree for parsing XML in CPython 3.3. Given the utterly poor performance of the pure Python library MiniDOM in this competition, I decided to give it another chance and tried the same in PyPy 1.7. Because lxml.etree and cElementTree are not available on this platform, I only ran the tests with plain ElementTree and MiniDOM. I also report the original benchmark results for CPython below for comparison.

Parser performance of XML libraries in CPython 3.3 and PyPy 1.7

While I also provide numbers regarding the memory usage of each library in this comparison, they are not directly comparable between PyPy and CPython because of the different memory management of both platforms and because the overall memory that PyPy uses right from the start is much larger than for CPython. So the relative increase in memory may or may not be an accurate way to tell what each runtime does with the memory. However, it appears that PyPy manages to kill at least the severe memory problems of MiniDOM, as the total amount of memory used for the larger files is several times smaller than that used by CPython.

Memory usage of XML trees in CPython 3.3 and PyPy 1.7

So, what do I take from this benchmark? If you have legacy MiniDOM code lying around, you want PyPy to run it. It exhibits several times better performance in terms of memory and runtime. It also performs substantially better for ElementTree than the plain Python ElementTree in CPython.

However, for fast XML processing in general, the better performance of PyPy even for plain Python ElementTree is not really all that interesting, because it is still several times slower than cElementTree or lxml.etree in CPython. That means that you will often be able to process multiple files in CPython in the time that you need for just one in PyPy, even if your actual application code that does the processing manages to get a substantial JIT speed-up in PyPy. Even worse, the GIL in PyPy will keep your code from getting a parallel speedup that you usually get with multi-threaded processing in lxml and CPython, e.g. in a web server setting.

So, as always, the decision depends on what your actual application does and which library it uses. Do your own benchmarks.

XML parser performance in Python 3.3

Dezember 9th, 2011

For a recent bug ticket about MiniDOM, I collected some performance numbers that compare it to ElementTree, cElementTree and lxml.etree under a recent CPython 3.3 developer build, all properly compiled and optimised for Linux 64bit, using os.fork() and the resource module to get a clean measure of the memory usage for the in-memory tree. Here are the numbers:

Parsing hamlet.xml in English, 274KB:

Memory usage: 7284
xml.etree.ElementTree.parse done in 0.104 seconds
Memory usage: 14240 (+6956)
xml.etree.cElementTree.parse done in 0.022 seconds
Memory usage: 9736 (+2452)
lxml.etree.parse done in 0.014 seconds
Memory usage: 11028 (+3744)
minidom tree read in 0.152 seconds
Memory usage: 30360 (+23076)

Parsing the old testament in English (ot.xml, 3.4MB) into memory:

Memory usage: 20444
xml.etree.ElementTree.parse done in 0.385 seconds
Memory usage: 46088 (+25644)
xml.etree.cElementTree.parse done in 0.056 seconds
Memory usage: 32628 (+12184)
lxml.etree.parse done in 0.041 seconds
Memory usage: 37500 (+17056)
minidom tree read in 0.672 seconds
Memory usage: 110428 (+89984)

A 25MB XML file with Slavic Unicode text content:

Memory usage: 57368
xml.etree.ElementTree.parse done in 3.274 seconds
Memory usage: 223720 (+166352)
xml.etree.cElementTree.parse done in 0.459 seconds
Memory usage: 154012 (+96644)
lxml.etree.parse done in 0.454 seconds
Memory usage: 135720 (+78352)
minidom tree read in 6.193 seconds
Memory usage: 604860 (+547492)

And a contrived 4.5MB XML file with a lot more structure than data and no whitespace at all:

Memory usage: 11600
xml.etree.ElementTree.parse done in 3.374 seconds
Memory usage: 203420 (+191820)
xml.etree.cElementTree.parse done in 0.192 seconds
Memory usage: 36444 (+24844)
lxml.etree.parse done in 0.131 seconds
Memory usage: 62648 (+51048)
minidom tree read in 5.935 seconds
Memory usage: 527684 (+516084)

I also took the last file and pretty printed it, thus adding lots of indentation whitespace that increased the file size to 6.2MB. Here are the numbers for that:

Memory usage: 13308
xml.etree.ElementTree.parse done in 4.178 seconds
Memory usage: 222088 (+208780)
xml.etree.cElementTree.parse done in 0.478 seconds
Memory usage: 103056 (+89748)
lxml.etree.parse done in 0.199 seconds
Memory usage: 101860 (+88552)
minidom tree read in 8.705 seconds
Memory usage: 810964 (+797656)

Yes, 2MB of whitespace account for almost 300MB more memory in MiniDOM.

Here are the graphs:

XML tree memory usage in Python 3.3 for lxml, ElementTree, cElementTree and MiniDOM

XML perser performance in Python 3.3 for lxml, ElementTree, cElementTree and MiniDOM

I think it is pretty clear that minidom has basically left the scale, whereas cElementTree and lxml.etree are pretty close to each other. lxml tends to be a tad faster, and cElementTree tends to use a little less memory.

PyCon-DE 2011

Oktober 12th, 2011

Die erste PyCon-DE überhaupt ist zu Ende gegangen. Sie war ein Riesenerfolg, sowohl für mich selbst als auch nach allem, was ich so von den anderen Teilnehmern gehört habe. Etliche interessante Vorträge aus unterschiedlichsten Bereichen, eine Menge Leute die ich entweder gerne wieder getroffen habe, immer schon mal treffen wollte, oder mit denen ich noch nie etwas zu tun aber nun einige interessante Diskussionen hatte. Die ganze Organisation lief wie am Schnürchen und sogar das Essen war ebenso gut wie abwechslungsreich.

Eines der wichtigsten Ergebnisse der Konferenz war die Gründung des Python Software Verband e.V. als Nachfolger der ehemals Zope-spezifischen DZUG. Die Neuausrichtung wird es wesentlich erleichtern, die deutschsprachige Python-Gemeinde unter ein gemeinsames Dach zu bringen, und die Python-Lobby in Deutschland, Österreich und der Schweiz zu verbessern.

Ich selbst habe zwei Vorträge über Cython und lxml gehalten, sowie ein Tutorial zu Cython. Alle wurden mit großem Interesse aufgenommen (wobei ich noch auf die konkreten Rückmeldungen zum Tutorial warte) und gaben Anlass zu einigen interessanten Diskussionen. Cython und lxml sind weiterhin zwei Best-of-Breed Tools, und große Themen in der Python-Gemeinde. Besonders lxml hat mir einiges an Schulterklopfen dafür eingebracht, dass ich es in den letzten Jahren zu dem einen großen XML-Tool für Python gemacht habe. Paul Everitt, der eine Keynote hielt und den ich eigentlich immer schon mal treffen wollte (hiermit passiert), hat sogar mitten in seinem Vortrag eine Riesenfolie aufgelegt, auf der nur zwei Namen standen - Martijn Faassen (der mit lxml angefangen hat) und ich. Werde ich also doch noch berühmt auf meine alten Tage …

Einige Zeit habe ich mit Kay Hayen diskutiert, der an einem statischen Python-Compiler namens Nuitka schreibt. Wenig überraschend stand er dabei vor etlichen der Probleme, in die wir auch mit Cython gelaufen sind. Er hat Recht damit, dass ich nicht gänzlich froh darüber bin, dass er ein separates Projekt begonnen hat anstatt uns mit Cython zu helfen, aber so ist OpenSource nun einmal. Jede/r hat das Recht, so viele Räder zu erfinden wie es Spaß macht. Soweit ich es verstehe, strebt Kay mit Nuitka eine Untermenge von dem an was wir aus Cython machen, aber kommt dabei von der anderen Seite. Cython war früher nur eine Erweiterungssprache und entwickelt sich nun zusätzlich zu einem vollwertigen Python-Compiler, wohingegen Nuitka einzig und allein die Nische des Python-Compilers füllen soll. Aber bisher hat Kay schon dabei einiges an Chuzpe und Durchhaltevermögen bewiesen, da warten vielleicht noch ein paar Überraschungen…

Es war interessant, einige Vorträge zu Themen zu sehen, mit denen sich auch mein Arbeitgeber herumschlägt - nur eben mit Python statt mit Java. So arbeitet beispielsweise eine interne Abteilung bei SAP an einer Web-basierten Client-Infrastruktur für SAP-Systeme in Python, inklusive Objekt-nach-SAP Mapper (ähnlich einem ORM), Offline-Caching-Mechanismen und so weiter. Im Vortrag sah es ganz so aus als könnte sich das allgemein als interessant für SAP-Clients erweisen, auch ganz unabhängig von Web-Anwendungen. Und es könnte bald schon OpenSource sein…

Ein weiterer Vortrag, bei dem ich mich gleich heimisch gefühlt habe, handelte von PyTAF, einem grafischen Framework zur Anwendungsintegration. Es wird intern bei der LBBW in Stuttgart entwickelt und erreicht mehr oder weniger das, was wir in Java machen. Darüber hinaus hat es ein GUI mit dem Datenintegrationsprozesse grafisch zusammengesetzt werden können, und es ist in Python geschrieben, was bei dieser Art von Software ein ernst zu nehmender Vorteil ist. Übrigens verwendet es intern lxml.objectify zur Datenverarbeitung - eine sehr gute Wahl :)

Die PyCon-DE im nächsten Jahr könnte ruhig wieder am selben Ort stattfinden. So gut, wie die diesjährige funktioniert hat, gibt es eigentlich keinen Grund zu wechseln. Obwohl sowas wie Berlin natürlich auch immer eine Reise wert ist …

PyCon-DE 2011 (en)

Oktober 12th, 2011

The first PyCon-DE ever is over. It was a huge success, both from my own POV and from what I heard from others. Quite a number of interesting talks from a very broad spectrum, loads of people that I either knew already, always wanted to meet, or had never heard of but found interesting to talk to. The organisation worked out impressively well, even the food was as good as it was diverse.

One of the major outcomes was the formation of the “Python Software Verband e.V.” as a successor to the previous Zope centered “DZUG e.V.”. The new direction will make it much easier to gather the German speaking Python community under a common umbrella, and to enforce the Python lobbying in Germany, Austria and Switzerland.

I gave two talks on Cython and lxml, as well as a tutorial on Cython. All of them were well received (although I”m still waiting for the final feedback on the tutorial) and gave the chance for interesting discussions. Both Cython and lxml continue to be best of breed tools and hot topics in the community, and I received a lot of backslapping for making lxml the one great XML tool for Python over the last few years. One of the keynote speakers, Paul Everitt, whom I wanted to meet for a while until I finally got the chance now, even put up a huge slide right in his talk with only two names on it, that of Martijn Faassen (the original author of lxml) and mine. I”m finally getting famous. ;)

I spent some time talking to Kay Hayen, who has written a static Python compiler called Nuitka. It was not surprising that he bumped into a lot of the problems that we met with Cython as well. He’’s right in that I”m not entirely happy about the fact that he started a completely separate project instead of helping with Cython, but that’’s OpenSource. People are free to reinvent as many wheels as they like. From what I understand, Nuitka aims to become a subset of what Cython heads for, just coming from a different side. Cython has originally been an extension language and is now additionally evolving into a Python compiler, whereas Nuitka is plainly targeted at being a Python compiler. But I wouldn”t mind getting surprised at some point. So far, Kay has certainly shown a remarkable investment and was pretty successful.

It was nice to see in a couple of presentations that the kind of things that the company I currently work for is doing in Java is done in Python in other places. For example, an internal department at SAP is developping a Web based client infrastructure for SAP systems in Python, including a transparent object-to-SAP mapper (similar to ORMs), offline caching mechanisms, etc. From the presentation, it sounded very much like this could be useful for talking to SAP in general, not only for web clients. And it may become open source at some point.

Another feel-alike talk was about PyTAF, a graphical application integration framework for financial applications that is being developped in-house at LBBW in Stuttgart. It aims to do more or less the same as the code we write in Java, but has a graphical frontend for putting together integration flows. And, it’’s Python, which is a serious advantage for this kind of software. It even uses lxml.objectify internally for data processing - best choice ever! :)

It may well be that next year’’s PyCon-DE will take place at the same location. It worked so well that there’’s no reason for a change. Although Berlin would also be a great location…

Fix URL display in Firefox 7

Oktober 12th, 2011

Firefox 7 comes with a very annoying “feature” that breaks copying from the URL bar by stripping away the protocol prefix from the URL. Here is how to fix it. The magic option in “about:config” is called “browser.urlbar.trimURLs”. Switch it off and Firefox starts working again.

PyCon-DE 2011

Juli 1st, 2011

Die PyCon-DE wird die erste, große Python Konferenz in Deutschland. Na endlich. Und: es werden noch Vorträge angenommen!