Summary: | libxml2 parser has a large performance overhead | ||
---|---|---|---|
Product: | WebKit | Reporter: | Patrick R. Gansterer <paroga> |
Component: | XML | Assignee: | Nobody <webkit-unassigned> |
Status: | NEW --- | ||
Severity: | Normal | CC: | annulen, ap, darin, eric, mrowe |
Priority: | P2 | ||
Version: | 528+ (Nightly build) | ||
Hardware: | All | ||
OS: | All | ||
Bug Depends on: | 45735, 52036, 41427, 45488, 45594, 45990, 50516, 50517 | ||
Bug Blocks: |
Description
Patrick R. Gansterer
2010-07-27 15:07:45 PDT
Long ago we used Expat. I don't remember why we switched to libxml2. (In reply to comment #1) > Long ago we used Expat. I don't remember why we switched to libxml2. because expat has no XLST support? If you're interested in this question, I suggest reading the svn logs in the xml directory in webcore. Trac.webkit.org. (In reply to comment #3) > If you're interested in this question, I suggest reading the svn logs in the xml directory in webcore. Trac.webkit.org. Wow, that's realy old code. ;-) I don't think that expat will be better than libxml. IMHO only a "native" WebKit parser can avoid the time-consuming memcpy/strcpy that any 3rdparty parser has. My expat implementation avoids the UTF16->UTF8->UTF16 conversation of libxml implementation, but there are unnecessary memcpy in the expat code anyway. >IMHO only a "native" WebKit parser can avoid the time-consuming memcpy/strcpy that any 3rdparty parser has.
Rapidxml does not have any memcpy/strcpy calls
(In reply to comment #5) > >IMHO only a "native" WebKit parser can avoid the time-consuming memcpy/strcpy that any 3rdparty parser has. > > Rapidxml does not have any memcpy/strcpy calls Rapidxml (like expat) has many missing features: e.g. namespace support. So it's not a real alternative for libxml2. |