Open Bug 1916542 Opened 1 year ago Updated 3 months ago

Avoid JS String conversion in strokeStyle / fillStyle setter, for faster lookup of the cached style for a string

Categories

(Core :: DOM: Bindings (WebIDL), enhancement)

enhancement

Tracking

()

People

(Reporter: mstange, Unassigned, NeedInfo)

References

(Blocks 1 open bug)

Details

(Whiteboard: [sp3])

Attachments

(5 files)

On the Charts-chartjs subtest of Speedometer 3, Firefox currently spends 4x as much time inside the strokeStyle setter as Chrome does.

Firefox: https://share.firefox.dev/4eb551Q (608 samples)
Chrome: https://share.firefox.dev/4e6Grj2 (148 samples, 4x faster)

The strokeStyle setter itself just looks up the string and finds the cached stroke style for it. However, Chrome is much faster at that string lookup.

In Firefox, 40% of the time is spent converting the JS string to an nsCString, and another 40% is spent hashing that string.

Can we do anything to eliminate the string conversion, and maybe even the hashing?

Here's roughly what Chrome does:

  // Internalize the string so that we can use pointer comparison for equality
  // rather than string comparison.
  v8_string = v8_string->InternalizeString(isolate);
  if (v8_string->Length()) {
    const auto it = color_cache_.Find<ColorCacheHashTranslator>(v8_string);

Peter, how easy is it for us to get atomized JS strings through our bindings to the C++ code?

Flags: needinfo?(peterv)
Duplicate of this bug: 1935846

It's not trivial. I'll put up a patch I've been trying out. Sadly it requires JSAPI usage outside of the bindings code, which we try to avoid.

These patches should work. Need to profile first, and then decide whether we want to do this or not.

Flags: needinfo?(smaug)
Flags: needinfo?(peterv)
Flags: needinfo?(echen)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: