Re: Re: Bundling libxml2 and expat compatibility layer

Hello, Well, if you don't like libxml2, you can still build the expat bundle... But yes, its surprising that you get such bad results. -- Regards. M.CHAILLAN Nicolas nicos@php.net www.WorldAKT.com Hébergement de sites internets. "Dmitri Dmitrienko" <dd@cron.ru> a écrit dans le message news: 20030504113655.94893.qmail@pb1.pair.com... > 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 > >