<p><a class="reference" href="http://www.reportlab.org/pyrxp.html">PyRXP</a> claims to be the fastest Python XML parser around... but this has a price. Once XML is parsed, you get a tree structured as tuples, lists and dictionnaries. While this is very Pythonic, it's not so trivial to write/read code handling such a tree.</p> <p>People at Reportlab argue about that for speed. Dealing with classes in Python is mem hungry, so they use only basic data structures (tuples,list,...). I can understand that but i believe it's an <cite>extremist</cite> point. Finding a balance between the DOM API (which is <cite>extremist</cite> too :) and such structures could turn to be more popular, maybe a Python <cite>xml_node</cite> builtin type ...</p> http://base-art.net/Articles/27/ 2006-03-12T20:56:07.000006+01:00 http://base-art.net/Comments/196/ Dj Mixer <p>ReportLab are proud to present pyRXP version 0.9, the fastest validating XML parser available for Python, and quite possibly anywhere :-).</p> <p>This is not a full DOM implementation, but we think it will do what 90% of the people want, in 10% of the time. And with validation. Enjoy!</p> <p><a class="reference" href="http://www.reportlab.co.uk/svn/public/reportlab/trunk/rl_addons/pyRXP/">http://www.reportlab.co.uk/svn/public/reportlab/trunk/rl_addons/pyRXP/</a></p> <p><a class="reference" href="http://mp3djay.com">http://mp3djay.com</a></p> 2004-12-26T10:31:40.000006+01:00 http://base-art.net/Comments/77/ Fredrik <p>According to my large-file benchmarks (large files, mostly ASCII, lot of elements, few attributes), Gnosis is nearly <em>10 times slower</em> than RXPU, and uses twice as much memory.</p> <p>ElementTree 1.2.1 (and later) under Python 2.3 (or later) is as close as you can get with a pure-Python solution, and that's still over 4 times slower and needs 25% more memory. The standard minidom is a little slower than that (but still faster than gnosis), but is extremely memory-hungry.</p> <p>So don't trust the pundits: RXPU is <em>extremely</em> fast, and very memory-efficient (and RXP is even faster, but more limited).</p> 2004-12-23T11:42:23.000003+01:00 http://base-art.net/Comments/73/ phil <p>Ian,</p> <p>Yes the tuple-list-dictionnary representation is fine, i'm ok with that. But then, you have to mix lamba forms, map() calls to extract usefull informations from the tree. I don't use such coding tricks very often (maybe should i ?), so it's not easy.</p> 2004-12-23T09:23:54.000003+01:00 http://base-art.net/Comments/72/ Ian Bicking I can't speak to the Unicode issues (assuming that's the flaw people are talking about with PyRXP). But I used RXP a while ago, and it seemed fine to me. Honestly, I don't find the tuple-and-list representation to be a problem at all. Certainly a representation using an efficient type would be preferable, but as long as you aren't actually exposing the tuples outside of your domain library, they seem like a reasonable compromise. Maybe with __slots__ (which postdate PyRXP?) the memory efficiency isn't as much of an issue -- though object construction time would still be a concern (assuming that tuples and lists are very fast to create). 2004-12-21T19:35:43.000001+01:00 http://base-art.net/Comments/71/ phil Ok, so i forget PyRXP forever ... i'm impatient to see PyRXPU compared to others (real?) parsers. The PyRXP's homepage is wrong so ... 2004-12-20T18:33:35+01:00 http://base-art.net/Comments/70/ verbat stop using PyRXP now. It's not an xml parser, and it should eb replaced by PyRXPU ASAP. Then, it would be slow, obviously. 2004-12-19T19:01:43.000006+01:00 http://base-art.net/Comments/69/ anon <p><a class="reference" href="http://www-106.ibm.com/developerworks/library/x-matters39.html">http://www-106.ibm.com/developerworks/library/x-matters39.html</a></p> <p>I'm pretty sure gnosis.xml.objectify is quite close in speed to pyRXP--especially if you compare to the Unicode-enabled pyRXPU that actually parses XML (rather than some XML-like non-standard language: see Uche Ogbuji's comments on this).</p> <p>At the same time: gnosis.xml.objectify nodes are as Pythonic as you can possibly get. Even more so, IMO, than those in ElementTree, for example.</p>