Confirmed users
1,016
edits
L20n/Firefox/Performance: Difference between revisions
Jump to navigation
Jump to search
add two more hypothesis
(add two more hypothesis) |
|||
| Line 136: | Line 136: | ||
==Hypothesis 7: Returning errors from MessageContext is slow== | ==Hypothesis 7: Returning errors from MessageContext is slow== | ||
I noticed on Cleopatra that <code>entitiesFromContext</code> takes ~6ms but it only spends 1ms in <code>format</code>. <s>Are we paying for transforming the data structure that we get from the parser into a { value, attrs } object that the XUl bindings consume?</s> It looks like this is MessageContext.format's fault after all. Creating an empty errors array is costing us 2-3 ms. If I pass the array as an argument to append errors to, the whole thing takes 10-11 ms (13-14 ms before). I filed {{bug|1301198}}. | I noticed on Cleopatra that <code>entitiesFromContext</code> takes ~6ms but it only spends 1ms in <code>format</code>. <s>Are we paying for transforming the data structure that we get from the parser into a { value, attrs } object that the XUl bindings consume?</s> It looks like this is MessageContext.format's fault after all. Creating an empty errors array is costing us 2-3 ms. If I pass the array as an argument to append errors to, the whole thing takes 10-11 ms (13-14 ms before). I filed {{bug|1301198}}. | ||
==Hypothesis 8: I/O cache impact tpaint== | |||
Because tpaint launches 20 windows, 19 of them use cached I/O. We disabled the cache to see how it impact tpaint results. | |||
[https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=65cba468defc&newProject=try&newRevision=1d23b2721e83&framework=1&showOnlyImportant=0 The results] indicate that there's no impact of I/O cache on tpaint - disabling it doesn't change results. | |||
==Hypothesis 9: Caching parsed entries instead of strings will impact tpaint== | |||
On larch we cache the strings we load (see Hypothesis 8), but we do parse the string every time. Our census indicates that parsing costs around 5ms, but we also have to copy a large string between L10nRegistry JSM, bindings, back to IntlMessageContext JSM where we parse it and then carry it back to bindings. | |||
[https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=65cba468defc&newProject=try&newRevision=f328389107a3&framework=1&showOnlyImportant=0 The results] indicate that moving parsing to be done within L10nRegistry and cached does shave off ~9ms on tpaint and 6ms on tpaint(e10s). | |||
That indicates that there's more than just parsing time that we shave off, but we also store more in memory (JSON objects instead of strings) and it mostly impacts tpaint test (opening the same window 20 times) rather than actual real life user experience (launching UI once). | |||