thanks for the analysis :) I just skimmed over the tabl of contents and this caugth my eyes. Le 14/7/16 à 01:58, monty a écrit :
Thanks for the link.
In-place parsing is a non-starter because it means storing the entire input as a string in memory, so you could only parse files that fit in Pharo's address space. The multi-gigabyte OpenStreetMap docs the article mentions would be unparsable with SAX in a 32-bit VM.
Linked lists for storing child nodes is common (LibXML2 and Xerces do it) and provides constant time insertion and sibling access, but arrays/vectors (Arrays/OrderedCollections) are more cache friendly and faster for sequential access and in Pharo are almost always the correct choice.
There is always the option of an FFI-based parser, but it shouldn't be a hybrid like Python's minidom (FFI Expat with a Python DOM implementation), because something like that already exists in Smalltalk/X (FFI Expat with a Smalltalk DOM) and it was slower than a St/X port of XMLParser in my tests (I assume due to the FFI overhead), so it's probably not worth it. But a non-hybrid parser with everything (including the DOM) done in C should definitely be faster.
Sent: Wednesday, July 13, 2016 at 10:27 AM From: stepharo <stepharo@free.fr> To: "Pharo Development List" <pharo-dev@lists.pharo.org> Subject: [Pharo-dev] tricks for XML parsing.
Hi guys
these free books may be interesting for you
http://aosabook.org/en/posa/parsing-xml-at-the-speed-of-light.html
stef