formatEntities is an internal method used only in LocalizationObserver.getElementsTranslation. As evidenced by bug 1289530 we spend quite a lot of time in getElementsTranslation. I'd like to ry to optimize both methods perf-wise.

I run a few tests using Zibi's l20n-perf-monitor [1]. At first I suspected the slowness to be related to this.iteractive in formatEntities or the destructuring assignment in getElementsTranslation's map() (which tends to be slow as of today). I can now confirm that formatting takes up to 20 ms which is almost all of what getElementsTranslation takes. [1] https://github.com/zbraniecki/gecko-dev/blob/l20n-zibi/toolkit/content/l20n-perf-monitor.js

Not sure if it's relevant here, but I have seen things like map(), etc. perform slower than a traditional `for (var i < 0; i < length; i++) { ... }` loop, so it might be worth an attempt if you are in a hot code path.

Thanks, :jryans! I'll experiment

(Accidental Submit.( I'll experiment with regular for loops (and perhaps for-of) but so far it looks like the most expensive thing is iterating over the NodeList returned from querySelectorAll('[data-l10n-id]'), no matter how.

Most of the perf problems are in format* functions or in the MessageContext class. I found three major bottlenecks: * destructuring assignment is slow in hotter loops, * formatting traits bails out of the simple-string optimization because the entire trait object is passed to format() instead of its <code>val</code>, * formatting entities with null values and no default traits is slow because we check each trait if it's a default one deep in the generator-enabled code of MessageContext; we could make this check much earlier.

This brings formatting (keysFromContext) from 20ms down to 9ms. I'll run a few more experiments before asking for review.

Perfherder numbers have low confidence due to the small sample but they're consistent with what I'm seeing locally: https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=ccade2a11d17&newProject=try&newRevision=c57005f7a569&framework=1&filter=tpaint&showOnlyImportant=0 There seems to be a small improvement in tpaint numbers. I think this is ready to land.

Comment on attachment 8785010 [details] Bug 1296618 - Part 4: Remove destructuring of [value, errors] arrays. https://reviewboard.mozilla.org/r/74318/#review72310

Comment on attachment 8785009 [details] Bug 1296618 - Part 3: Remove destructuring of [id, args] arrays. https://reviewboard.mozilla.org/r/74316/#review72308

Comment on attachment 8785008 [details] Bug 1296618 - Part 2: Optimize entities with null values and no default traits. https://reviewboard.mozilla.org/r/74314/#review72306

Comment on attachment 8785007 [details] Bug 1296618 - Part 1: Format trait.val directly. https://reviewboard.mozilla.org/r/74312/#review72304

https://hg.mozilla.org/projects/larch/rev/aa591eaf759c385e131bec79f0262976d195d209 Bug 1296618 - Part 1: Format trait.val directly. r=gandalf https://hg.mozilla.org/projects/larch/rev/38d37db7b551c7ecfa286178001b42502b9bc3bc Bug 1296618 - Part 2: Optimize entities with null values and no default traits. r=gandalf https://hg.mozilla.org/projects/larch/rev/5d24f47b89d6d130a18d0b1a883c1e8c35c10f67 Bug 1296618 - Part 3: Remove destructuring of [id, args] arrays. r=gandalf https://hg.mozilla.org/projects/larch/rev/468244986b20a0bdf22a5e36b55ae43ac09599c8 Bug 1296618 - Part 4: Remove destructuring of [value, errors] arrays. r=gandalf