1688312 - Consider to use nsAtoms in PerformanceEntry

Status: RESOLVED FIXED

(Core :: Performance: General, enhancement, P3)

Description

[Olli Pettay [:smaug][[e-mail]]]

Attachment: usertiming.html

There are lots of string comparisons when dealing with PerformanceEntries.
In many cases those could become simple pointer comparisons if nsAtoms were used.

However, creating atoms does add some overhead.
The testcase shows that creating 100000 entries on my machine goes from
~300ms to ~330ms, but accessing getEntriesByName (1000 times) goes down from ~800ms to
500ms with the patch I'm about to upload.

In theory using atoms is also more likely to share memory.

(I happened to notice this while looking at bug 1686930)

And yes, 100000 entries sounds like a lot, but that is what Facebook used until recently.

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

Attachment: Bug 1688312 - Consider to use nsAtoms in PerformanceEntry, r=sefeng

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

We might want to also just store the entries in totally different way.
Like a hashtable where name is used as the key and value is an array of entries with that name.
Though that wouldn't help too much because of entryType.

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

Attachment: usertiming_bytype.html

This is using different API, getEntriesByType.
If Chrome is really good with the other testcase using getEntriesByName, it is really bad
with getEntriesByType.
I had to lower the iterations from 1000 to 100 to ensure Chrome doesn't kill its child process.

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/bd266a6e1e78
Consider to use nsAtoms in PerformanceEntry, r=sefeng

Comment 5

[Dorel Luca [:dluca]]

https://hg.mozilla.org/mozilla-central/rev/bd266a6e1e78