Re: Re: Bundling libxml2 and expat compatibility layer

Hi Christian, I compared _parsing_, only parsing. Does it make sense ? Certainly, I expected some overhead for memory allocating when building DOM tree. I believe this overhead should be adequate. For example less than 3-5 times. But actually the overhead is much higher, incredibly higher. Could you explain what this time is spent for ? Why xmlParseFile() is so slow ? Also, would be nice to hear your opinion why xmlFreeDoc() is slow... It should only free allocated memory, nothing above. I expected 1-10ms for it while actially got 133ms, quite comparable with time for parsing. Also, why xmlParseMemory() is 3 times slower than xmlParseFile() ??? It can't be explained easily, I guess. I think libxml2 is a really SLOW library, purely slow, and will not satisfy people who concern about performance. -Dmitri >I didn't look at Sterlings code yet, but you can't compare SAX parsing of >expat with DOM parsing of libxml2. Libxml2 however does support SAX, as >well and I assume (and hope) Sterling used only this for ext/xml >replacement (making an in-memory DOM-Tree per default in ext/xml would >make a lot of people very unhappy ;) ) > >Dmitri, what exactly did you compare? > >chregu On Sun, 4 May 2003, Dmitri Dmitrienko wrote: > Hi, > > Sterling, before doing such a weird thing of moving everybody to libxml2 > please compare performance of what we have with expat and what we'll get > with libxml2. > > I tested them both with quite a big xml file ~500kB. Expat parsed doc in > 19ms while libxml2 in 267ms. > It is 14 times slower. I understand that there is a big difference between > what expat does and what libxml2. > On the other hand, there are some 3rd party xmldom-libraries that parse > xmlfile to xmldom in ~ 110-130ms. > At least two times faster. > > Also should be noted that libxml2 spends INCREDIBLY long time when freeing > parsed document 133ms. > Moreover, when I tried to parse pre-loaded document (xmlParseMemory), it > showed even worse results 786ms. > > I believe it's too early to switch to this library. At least there some > reasons to think more about. > > Best regards, > Dmitri. > > > "Sterling Hughes" <sterling@bumblebury.com> wrote in message > news:1051978274.11377.131.camel@hasele... > > Hi, > > > > Well, OK, I have libxml2 successfully bundled with PHP, and I've further > > gone ahead and created a C-level compatibility layer which maps expat > > <-> libxml2. I've also moved the detection logic for both expat and > > libxml into php5/bundle/libxml and php5/bundle/expat respectively. This > > way you can choose your backend at the configure line, and things will > > work transparently (by default, expat and libxml are compiled in, and > > the XML extension uses expat). I've also done the "namespace > > redefinition" heavy lifting - I'm not quite sure it works, but I have > > renamed most (from what I can tell, all) public symbols, like with > > expat. I'm sure this could be ironed out pretty easily if I made any > > mistakes. > > > > As far as I'm concerned, the important thing here is bundling libxml2. > > I think everyone who is implementing XML support around PHP will agree > > that expat just isn't meeting our needs, specifically: > > > > 1) The ability to easily access and modify XML documents from within a > > programatic structure, alá DOM (this would also make it easy for me to > > implement my SimpleXML[1] extension). > > > > a) The ability to query an XML document via Xpath > > > > 2) The ability to validate an XML document against either a DTD or a XML > > Schema (very important, especially for SOAP.) > > > > 3) Proper unicode support > > > > 4) Support for XPointer and XLink > > > > 5) Support for Docbook and HTML parsing > > > > 6) Expat doesn't even full support the same capabilities that libxml2 > > does when it comes to SAX processing. > > > > However, when we bundle expat with PHP, and make ext/xml therefore an > > "always available" extension. We create the illusion that it is the > > "recommended" and "best" solution for XML parsing with PHP, when in > > fact > > it really isn't. > > > > Our needs as far as XML support are growing, whether it be implementing > > technologies that exist on top of XML (SOAP, WSDL, RDF) or implementing > > extensions that make it easier to access XML (SimpleXML, DOM), expat > > makes it way to hard (for all intensive purposes, impossible) to > > implement these systems. > > > > Therefore, I'm suggesting that we bundle libxml2, while (for now) > > keeping in expat as well. This will cause *absolutely* no backwards > > compatibility changes, while at the same time, it will allow you to use > > only libxml2 for XML processing (--without-bundle-expat), with 97% [2] > > backwards compatibility maintained. > > > > -Sterling > > > > [1] > > http://news.php.net/article.php?group=php.xml.dev&article=6 > > [2] This is one of 54% of facts made up on the spot. Suffice it to say > > that the new extension is "mostly" backwards compatible, and the places > > where it breaks, shouldn't have been relied upon anyway. > > > > -- > > "Reductionists like to take things apart. The rest of us are > > just trying to get it together." > > - Larry Wall, Programming Perl, 3rd Edition > > > > > > -- nam...christian stocker adr...pflanzschulstr. 31, ch-8004 zurich pho...+41 43 317 9984 www...http://blog.bitflux.ch mob...+41 76 561 8860 ema...chregu@phant.ch wor...+41 1 240 5670 gpg...0x5CE1DECB