Re: Bundling libxml2 and expat compatibility layer

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 >