Confirmed users
1,016
edits
L20n/Firefox/Performance: Difference between revisions
no edit summary
No edit summary |
|||
| Line 62: | Line 62: | ||
The results: ''(a)'': 2.05 ms, ''(b)'': 0.18 ms, ''(c)'': 2.40 ms. | The results: ''(a)'': 2.05 ms, ''(b)'': 0.18 ms, ''(c)'': 2.40 ms. | ||
===Using MutationObserver instead of qSA at startup=== | |||
:wchen suggested that instead of using qSA to capture links and localizable nodes, we should use MutationObserver. I shared our testing results that indicate that MutationObserver is slow and we discussed potential reasons and what can we do to speed it up. | |||
The conclusion is a three-tier approach: | |||
* Filter out non-data-l10n-id elements on C++ side so that they never fire onMutations | |||
* Gather all data-l10n-id elements feed from the HTML/XUL parser and deliver a single MutationRecord for all of them just before layout | |||
* Dive into childNodes of MutationRecords and only report to us the ones that have data-l10n-id so that we don't have to querySelector into childNode DOMFragments | |||
: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. | |||
==Previous Research== | ==Previous Research== | ||