Re: Re: Bundling libxml2 and expat compatibility layer
| From: | Dmitri Dmitrienko | Date: | Sun, 04 May 2003 20:00:12 +0000 |
| Subject: | Re: Re: Bundling libxml2 and expat compatibility layer | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-1237@lists.php.net to get a copy of this message | ||
Christian,
>xmlParseFile does build a DOM-Tree out of your
> XML-Document, which is of
>course slower than the SAX-parsing expat is doing..
It is not obvious conclusion that any XMLDOM parsing should be slower.
More over it is competely wrong if you compare libxml2 vs expat.
If you think more you'll see that DOM-parser only allocates nodes and link
them in lists.
Should it be so much slower ??? Are you sure that allocating nodes should
slow down everything by 14 times ?
I believe it is not.
Also I don not see any reasonable explanation why libxml disposes document
so slow.
It does not need verify, it does not need parse, it's only fries nodes.
NOTHING MORE.
And takes nearly the same time as allocating/parsing and verifying.
The only obvious conclusion is that all algorithms are written
inefficiently.
I'm not against XML DOM and it's benefits. I'm against wrong and inefficient
algorithms.
People, why don't you read Donald Knouth's books ?
>_But_ libxml2 can parse your XML document in SAX-style only without
>building an DOM-Tree. Without looking at Sterling's code, I assume,
>that's what he did and you should compare this code to expat and _not_
>xmlParseFile..
libxml2-2.5.7,parser.c:10670
xmlDocPtr
xmlParseDoc(xmlChar *cur) {
return(xmlSAXParseDoc(NULL, cur, 0));
}
I think the code excerpt shown above is a good answer to your arguments.
> libxml2 is certainly not slow, it has a well known reputation as being
> very fast for what it does.
I would not discuss reputation. It's a competely different thing.
As with performance, I still insist that libxml2 has a) pretty slow parser
due to inefficient algorithms and b) pretty slow in some other respects
including freeing documents once again due to inefficietn algorithms.
-Dmitri.