Confirmed users
1,016
edits
L20n/Firefox/Performance: Difference between revisions
no edit summary
No edit summary |
|||
| Line 78: | Line 78: | ||
:wchen said he'll give us a POC patch for (1) and he hopes that it'll fix majority of the performance hit we see. If that will not solve it, he'll help us profile the DOM operations further and we can then consider adding (2) and (3) but that may take a bit more time to hack. | :wchen said he'll give us a POC patch for (1) and he hopes that it'll fix majority of the performance hit we see. If that will not solve it, he'll help us profile the DOM operations further and we can then consider adding (2) and (3) but that may take a bit more time to hack. | ||
The (3) ended up not being needed. The way MutationObserver works in XUL is that it always returns single elements, not DOMFragments. | |||
I tested (1) with :wchen's patch and it ended up not improving performance. Further analysis (read below) indicates that neither would (2). | |||
===DOM optimizations - end of path=== | |||
After testing the previous approach and some other ideas, :wchen profiled our work and came to conclusion that there's basically nothing more we can do to reduce the performance penalty on querying through DOM or applying translations to DOM. | |||
Quoting :wchen: | |||
"I profiled the test case and it looks like the main reason for slowness is in creating a js reflector of elements with XBL bindings. We need to install the XBL binding on each element when we create the js object (your test cases is doing this when Array.from touches the elements). I can't think of any optimizations to work around it, you're going to have to pay that cost somewhere if you want to touch the object in js because we set up the js prototype during binding installation." | |||
If we want to touch elements without creating the js object, we'd have to, quoting :wchen: "do it in c++ :(". | |||
===JIT optimizations - end of path=== | |||
I worked with :shu to profile our code with JIT Coach, and it seems that our code jits pretty well. There are several things we can optimize further by asking JIT team to inline certain functions we use a lot (String.prototype.slice, String.prototype.indexOf etc.), but it doesn't seem like it would have any significant impact on our perf. | |||
One other interesting aspect is that in several places our code gets run enough times to get JITted, but not enough to benefit from the JITting and we end up with the short end of the stick. Nothing we can do about it. | |||
My current position is that I'll file those bugs and we'll get a bit more inlining but I don't expect us to get a significant enough return on investment to move talos numbers this way. | |||
==Previous Research== | ==Previous Research== | ||