Bug 41427 – Add expat based XMLDocumentParser

• Status: RESOLVED
• Resolution: WONTFIX
• Component: XML

[Patrick R. Gansterer]

see patch

[Patrick R. Gansterer]

Created attachment 60147 [details]
Patch

[Darin Adler]

Comment on attachment 60147 [details]
Patch

Why?

We really don’t want a third one of these!

[Patrick R. Gansterer]

(In reply to comment #2)
> (From update of attachment 60147 [details])
> Why?
The main reason was that I had problems to get libxml working.

When you look at the libxml parser you have many toString() calls, which do UTF-8 decoding. This isn't necessary with expat, because it can return UTF-16 strings directly.

I din't had the time to do performance tests, but expat is usually a little faster than libxml.

> We really don’t want a third one of these!
Then you won't accecpt a MSXML implementation too? (will save memory when using the windows system library)
What do you think about a "native WebKit XMLParser" with no 3rdparty dependency?

[Alexey Proskuryakov]

A native XML engine would be good in that it would allow for a much more efficient and compliant XSLT implementation, as well as sharing code with XPath. But it would take a lot of resources to write and maintain.

[Patrick R. Gansterer]

Some performance data*:

            libxml2        expat     percent
 5MB SVG:  0.7183sec     0.5356sec    -25%
10MB SVG:  1.6084sec     1.2298sec    -24%
20MB SVG:  5.4084sec     4.6952sec    -13%

* time from begin of first XMLDocumentParser::doWrite until end of XMLDocumentParser::doEnd, average of 3 measurements

[Alexey Proskuryakov]

A port that does not use libxml2 has no practical way to implement XSLT, is that correct?

[Patrick R. Gansterer]

(In reply to comment #6)
> A port that does not use libxml2 has no practical way to implement XSLT, is that correct?
Yes that is correct, libxlst needs libxml2. I don't think that expat is a real option for "fat clients" but as an alternative without XLST support (on small devices).
The table in comment #5 shows that there is much room for improvements in the XML parser.

[Adam Barth]

Comment on attachment 60147 [details]
Patch

I really don't like the idea of adding a third (!) XML parser.  It's bad enough that we have three.  If we can improve perf by switching our XML parser, that's great, but we should kill the old one.  IMHO, adding the second XML parser was a mistake too.

[Patrick R. Gansterer]

(In reply to comment #8)
> (From update of attachment 60147 [details])
> I really don't like the idea of adding a third (!) XML parser.  It's bad enough that we have three.  If we can improve perf by switching our XML parser, that's great, but we should kill the old one.  IMHO, adding the second XML parser was a mistake too.
I agree with you 100%. My expat version was mainly a quick hack to show the possible speed increase of the XMLParser. It can't be a full replacement beacause of the missing xlst support :-(.
I've created a new bug for this issue at bug 43085.
I think there is no way around to implement a full native WebKit XMLParser?