47 bytes, text/x-phabricator-request
|Details | Review|
Loading a large memory report in about:memory is slow. For example when I load a memory report file with around 12,000 reports in it, the main thread is blocked for around 2 s. Profiling reveals that more than half of the time is spent in Number.toLocaleString. That's unfortunate, since it's a convenient API, but reimplementing just what we need helps a lot. With the forthcoming patch, the time spent under formatNum on this file I was testing with drops from 1200 ms to 10 ms. (Making report formatting faster is important for bug 1517175, where my patch will reformat upon typing in a new filter string.)
Aw geez, I just got rid of the old hand-rolled formatting code in bug 1499906 :( The fact that the JS code in the patch, which doesn't look particularly fast, is nonetheless vastly faster than toLocaleString() suggests that the implementation of toLocaleString() has perf problems. Jason, do you have any thoughts about that?
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/a52b66841df9 Improve about:memory performance by not using toLocaleString r=njn
Thanks for the needinfo on this. By coincidence, I recently filed a bug about this. Bug 1514851.
You need to log in before you can comment on or make changes to this bug.