https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=0e41d07a703f&tochange=b07db5d650b7 https://treeherder.mozilla.org/perf.html#/graphs?timerange=604800&series=%5Bmozilla-central,dd55da63ebce86ee3867aa3b39975c2a90869ce2,1,1%5D&zoom=1499649915180.0818,1499786925611.8691,275,356.9402893977379 I'm bisecting. Stay tuned.

(I suspect the error reporting patch, fwiw)

bz thinks this is likely related to the CSS error reporting. Many tests didn't change at all, but dailymotion got 3.5x slower (which could be explained by a lot of invalid CSS). Confirming with try pushes.

Bingo, it's the CSS stuff. Comparison: https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=a0a88371838908a340d6e76cae53acd6a3f307eb&newProject=try&newRevision=918ee0dd627860de08cd450a803e74d4ba29da2f&framework=1&filter=tp5&showOnlyImportant=0 The two important regressions here are Tp5o and Tp5o private bytes. If you click the subtests for Tp5o, you'll note that dailymotion and youtube stand out as enormous regressions. https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=a0a88371838908a340d6e76cae53acd6a3f307eb&newProject=try&newRevision=9654b62684a9fde97c7986e62fc3ff080b225cda&framework=1&filter=tp5&showOnlyImportant=0 Here is a comparison with jdm's error reporting fix from bug 1380488 applied: https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=a0a88371838908a340d6e76cae53acd6a3f307eb&newProject=try&newRevision=9654b62684a9fde97c7986e62fc3ff080b225cda&framework=1&filter=tp5&showOnlyImportant=0 You'll notice that the memory regression is gone, but that the perf regression is still there.

(Note that the second and third links are the same, I just pasted the middle one by accident). Note that "still there" is a bit of an oversimplification, because the memory patch reduces the performance impact considerably. However, there is still a sizeable regression remaining.

Per IRC discussion, we should at the very least duplicate the NonMozillaVendorIdentifier check that Gecko's CSS parser does to avoid error-reporting property names that start with '_' or '-' but not "-moz-". That might eliminate a bunch of the error reporting we're doing right now.

Profiling revealed two hotspots - one is that the UTF-8 -> UTF-16 conversion for the CSS source text is a hot path that dominates the error reporting path (up to 70%). The other is that Stylo currently reports many more errors on dailymotion than Gecko does, which causes us to start dropping previously buffered nsScriptError values while reporting new ones, leading to many deallocations that take up to 30% of the time. A significant source of the extra errors is that Stylo reports unrecognized vendor-prefixed properties as errors, unlike Gecko: http://searchfox.org/mozilla-central/rev/cbd628b085ac809bf5a536109e6288aa91cbdff0/layout/style/nsCSSParser.cpp#7165-7169 . I've filed https://github.com/servo/servo/issues/17736 for the second issue.

If I remove the actual CSS source from the error message, the profiles I get are indistinguishable from the Gecko ones. jryans has agreed that the source line is not actually used anywhere outside of devtools tests, so I'm going to go ahead and pass an empty string instead of real source code.

Try run at https://treeherder.mozilla.org/#/jobs?repo=try&revision=86d1736f1500c5a32da549a7592b339c08dba85c

Comment on attachment 8886715 [details] [diff] [review] Provide an empty string as the CSS source text in parser errors In the interest of fixing the performance problem ASAP, I'm going to land a more targeted fix and file a followup to finish this patch the right way.

bholley gave this r+ over IRC. It is necessary to land after https://github.com/servo/servo/pull/17738 merges to autoland.

Is there a gecko bug tracking https://github.com/servo/servo/issues/17736 ?

Bug 1381195.

Pushed by kwierso@gmail.com: https://hg.mozilla.org/integration/autoland/rev/610ba2072434 Remove CSS source text from parsing errors. r=bholley a=bustage