Summary: [Meta] Implement a profiler feature → [Meta] Implement a profiler feature to report cost of style changing and why it costly in Gecko
While checking layout/restyle/reflow performance issue, it usually need a lot of code tracing, and the CSS author is hard to tell what makes it slow. For example, in bug 110625, we change a simple class of a container div, but results in thousand times of style matching. From https://bugzilla.mozilla.org/show_bug.cgi?id=1110625#c58, such change should be lightweight since the subtree is not relevant. However, the class change in the case cause a RestyleSubtree because of a CSS rule of "not(.maximized) xxx xxx" and makes tons of restyle in that case. And in fact, all matching is fail, so it just waste time in match. We should provide a tool to show such information directly and make performance tuning easier.
If we can integrate this counter to WebIDE and it would be great to gaia developer to know how much these counters grow based on different implementation.
(In reply to peter chang[:pchang][:peter] from comment #2) > If we can integrate this counter to WebIDE and it would be great to gaia > developer to know how much these counters grow based on different > implementation. The best would be integrate the Style Editor of WebIDE with a try restyle run profiler to get the real impact of specific change in style. And the coun3qter should contains at least the time of restyle/reflow/repaint and the style matching times. A description of what kind of restyle must be done for such style change, e.g, subtree or self should be informative, too. A problem of most of these things is: they may affect performace, and most such information is only available in debug build.
[Tracking Requested - why for this release]:
tracking-b2g: --- → backlog
You need to log in before you can comment on or make changes to this bug.