Confirmed users, Bureaucrats and Sysops emeriti
2,976
edits
L20n/Firefox/Performance: Difference between revisions
Jump to navigation
Jump to search
→Potential Performance improvements
| Line 32: | Line 32: | ||
== Potential Performance improvements == | == Potential Performance improvements == | ||
Based on the experiments we did, there's a couple of short-comings in the platform. When one of those short-comings are optimized, that could open up optimizations in the l20n.js code. | |||
=== Optimize DOM pathways we use extensively === | |||
:smaug is profiling our code trying to find ways to reduce the cost of Element reflections and applying translations. http://searchfox.org/mozilla-central/source/dom/base/Element.cpp#455-458 is a good starting point. | |||
=== Stylo === | |||
Stylo may significantly improve the cost of Node reflection that is currently, according to :smaug, slowed down by CSS checking for XBL bindings. | |||
=== JIT optimizations === | |||
There are two parts of l20n bootstrap that are JS heavy - FTL parsing and Entry formatting. bholley would like to add code paths to JIT that are dominent in our js code. | |||
=== Caching === | === Caching === | ||
We're currently caching I/O, | We're currently only caching I/O. At a point where the timing of l20n.js isn't dominated by DOM/CSS, we should consider the impact of caching | ||
* | * MessageContext or Localization objects | ||
* | * formatted entries | ||
Caching | Caching formatted entries would be significantly more engineering work than MessageContext or Localization objects. | ||
=== Move DOM operations earlier === | === Move DOM operations earlier === | ||
| Line 47: | Line 60: | ||
Currently, the best tpaint times gives us executing DOM operations on document.readyState === 'complete'. | Currently, the best tpaint times gives us executing DOM operations on document.readyState === 'complete'. | ||
That means that we're waiting for a lot of time between when DOM is completed and when we operate on DOM potentially causing reflows. | That means that we're waiting for a lot of time between when DOM is completed and when we operate on DOM potentially causing reflows. | ||
Unfortunately, attempting to start DOM operations between when parsing is done and when layout starts results in worse tpaint times | Unfortunately, attempting to start DOM operations between when parsing is done and when layout starts results in worse tpaint times. | ||
The possible cause of it, according to :smaug, is that operating on DOM before layout may require costly CSS lookups for XBL bindings. It's possible that stylo may solve some of that. | The possible cause of it, according to :smaug, is that operating on DOM before layout may require costly CSS lookups for XBL bindings. It's possible that stylo may solve some of that. | ||
Another possibility that we're experimenting with is triggering localization to happen after layout but before reflow. | Another possibility that we're experimenting with is triggering localization to happen after layout but before reflow. | ||
As soon as the DOM/CSS interaction is quick, we could investigate the possible impact. | |||
==Research Avenues== | ==Research Avenues== | ||