Bug 52547

Created attachment 79117 [details] Patch

This is a test, to check the performance of the xml parser changes in bug 52036. In contrast to the other parser tests this one reads the (UTF-8) data from disk, instead of using (UTF-16) data from javascript. This also takes the input encoding into account. When you only change the file extension from xhtml to html you can compare the performance of HTML vs. X(HT)ML parser. I used a 5MB XHTML file and got the following results: avg median stdev min max XML 6254.5 6366 573 5462 7118 HTML 6517.25 6770.5 505 5242 7286 +4,2% +6,3% (After the patch at bug 52036 the difference goes up to 10%) BTW: Maybe you have a better name for the files and a good content for the xhml file. I'm not very good in finding names. :-/ PS: webkit-patch wasn't able to upload the patch with the 5MB file and didn't show any error.

Comment on attachment 79117 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=79117&action=review > PerformanceTests/Parser/resources/runner.js:72 > + function subRun(remaining) { subRun? What does that mean? > PerformanceTests/Parser/resources/runner.js:77 > + } else { prefer early return. > PerformanceTests/Parser/with-onload.html:13 > + document.body.removeChild(iframe); > + finished(); Do you mean to time the destructor here? Also, you might consider just timing until DOMContentLoaded.

> Do you mean to time the destructor here? Also, you might consider just timing until DOMContentLoaded. That might be past the attachment size limit for bugs.webkit.org. I suspect we don't handle that error gracefully.

Created attachment 79759 [details] Patch (In reply to comment #3) > Also, you might consider just timing until DOMContentLoaded. Hmm, i wasn't able to use this event on the iframe.

Comment on attachment 79759 [details] Patch OK. I still think DOMContentLoaded would be better. Did you try iframe.contentWindow.addEventListender("DOMContentLoaded") ?