Performance issue in CSSStyleDeclaration::set_property

[glennw]

I'm profiling the Multiply test in the MotionMark benchmark suite - the major bottleneck in this test is the rAF call.

In this test, most of the time is spent in the (many) calls to set_backgroundColor and set_Transform.

If we zoom in on these calls, we seem to spend a lot of time in the ToCss implementation, and also quite a lot of time in SharedRwLock::read.

@emilio mentioned in another bug:

We should also look into not serializing the style attribute eagerly when it's
not needed... But a lot of code currently rely on attribute values being
dereferenciables to &str, so that's harder to fix.

Questions:

1. Is that ToCss call here actually needed? It sounds like @emilio was saying it's calculated here when it isn't actually needed, and could perhaps be done lazily?
2. Is there anything we can do about the time spent in the lock primitive?

If removing the ToCss call here is feasible, that could potentially halve the cost of our setProperty calls, which would be a massive win in this benchmark.

[glennw]

cc @emilio @jdm @bholley @SimonSapin since I'm not sure who knows this stuff best.

[glennw]

Hmmm, I wonder if there is a (relatively) easy way I could hack out the ToCss usage in setProperty, for testing the potential improvement locally?

[glennw]

Applying the follow diff as a hack changes the frame rate on my machine from 39 to 52 fps in this test.

diff --git a/components/script/dom/cssstyledeclaration.rs b/components/script/dom/cssstyledeclaration.rs
index 2ef448720d..bdea3c3877 100644
--- a/components/script/dom/cssstyledeclaration.rs
+++ b/components/script/dom/cssstyledeclaration.rs
@@ -85,8 +85,8 @@ impl CSSStyleOwner {
                     //
                     // [1]: https://github.com/whatwg/html/issues/2306
                     if let Some(pdb) = attr {
-                        let guard = shared_lock.read();
-                        let serialization = pdb.read_with(&guard).to_css_string();
+                        //let guard = shared_lock.read();
+                        let serialization = String::new();//pdb.read_with(&guard).to_css_string();
                         el.set_attribute(&local_name!("style"),
                                          AttrValue::Declaration(serialization,
                                                                 pdb));

[SimonSapin]

ToCss here is used to update the string backing Element.getAttribute("style") and selectors like [style^=font]. It looks like this is done eagerly whenever a setter of Element.style.something is used. Instead we should have a "dirty bit" and only serialize lazily when we need the actual string. This is tricky in particular for the selector case because we do selector matching on multiple threads, so some form of synchronization is needed. It likely can’t be SharedRwLock::write on a document-wide or process-wide lock because that would conflict (and possibly deadlock) with other threads.

[emilio]

I think the right fix for this, in particular for the style attribute is not storing the serialized string anywhere. This also applies for other attribute values, fwiw...

[SimonSapin]

Gecko serializes and caches the string on demand, but does not cache when in a servo restyling traversal (i.e. when off-main-thread).

case eCSSDeclaration in void nsAttrValue::ToString(nsAString& aResult) const

[metajack]

@emilio are you working on this? If so, do you have a rough timeline? We're hoping to get this fixed for demos at all hands, but we can use the hack to disable serialization as a stop gap for next week if needed.

[bholley]

I think this may be marginally more up @SimonSapin's alley, given that he's looking into parsing/serialization performance on stylo right now. But it's probably more a question of who has cycles to look at it.

[SimonSapin]

@pcwalton, you said on IRC you’d try to remove Deref<Target=str> for AttrValue. How did that go?

[pcwalton]

I started but stopped working on it because @emilio said that he was working on it.

[pcwalton]

I was using khuey's lazy-init crate. @emilio, can you explain how you wanted to solve it?

[emilio]

My idea was to remove the Deref<Target=str> in all the attributes, as well as the Strings in all of them, and passing the read-only lock to the users of serialize(), that are left only in DOM APIs.

Current WIP is https://github.com/emilio/servo/tree/attrs. That requires implementing parse_plain_attribute for a few attributes, mainly:

lang -> atom
name -> atom
href -> string
<meta content>
encoding -> string
<style media> -> string
<script type> -> string
<script for> -> string
<script event> -> string
<script src> -> string
<script language> -> string
<textarea placeholder> -> string
<button type> -> atom
<input type> -> atom
<object data> -> string
<table cellspacing> -> u32
<tc span> -> string // FIXME
<li type> -> atom
<ol type> -> atom

Using lazy-init is, I guess, a slightly easier fix, but it doesn't feel like the right fix to me, there's no reason we should be storing all those strings in the first place.

[SimonSapin]

href -> string

Not URL?

[emilio]

It gets resolved when appropriate. At least that's how the code works as of right now, and element.href returns a string, not an url, I think.

[SimonSapin]

Oh, <base href> might change :/

[SimonSapin]

My idea was to remove the Deref<Target=str> in all the attributes, as well as the Strings in all of them

I don’t think we can remove String in most variants and preserve the behavior of Element.setAttribute. I’m opened #17476 that only removes String in the AttrValue::Declaration variant.