[webkit-dev] Writing a new XML parser with no external libraries
paroga at paroga.com
Wed Jun 29 01:04:36 PDT 2011
I had the "same idea" a year ago, and got only negative feedback.
My main intention was/is the performance of the parser (see ). I improved the performance of it a lot in the meantime (see dependencies of )
 tries to remove this UTF-8 -> UTF-16 -> UTF-8 overhead. The patch isn't perfect at the moment (some LayoutTest don't work, and it bypasses the whole DocumentWriter stuff).
So if someone really want to replace it, it would be great to check the performance against libxml2 with applied . Comment #1 at  shows that the current libxml2 implementation is about 6% faster than the HTML parser (same data, only different mime types).
So if we really want to add a new XML parser, someone should convert the HTML parser to work with the encoding of the document (or at least UTF-8) to add the required common code first, before adding a second parser with the same "performace problem" (sorry for that, i don't want to say that out parser is bad, i only see room for improvement).
> libxml2 has security bugs reasonably often, and creates the need for an extra upstream update to pull those fixes.
Isn't libxml2 a system library and _the system_ responsible for security issues in it?
Am 29.06.2011 um 07:10 schrieb Dirk Schulze:
> Am 29.06.2011 um 05:42 schrieb TAMURA, Kent:
>> I'm a little negative of developing a new XML parser. I'm afraid that the new parser introduces a lot of security/stability problems which existing parsers already resolved.
> I feel the same. Writing a new parser from scratch means introducing a lot of new security bugs, parsing errors and maybe bigger performance lost at the beginning. Speaking from the SVG side, we fail at least three tests on the W3C SVG Test Suite because of parsing bugs if libxml2 on MacOS. All of these bugs are fixed in later versions of libxml2. Updating libxml2 more often on MacOS would help a lot.
> With the new parser we won't loose support XSLT and XLink support?
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
More information about the webkit-dev