1485402 - SVG rendering triggers slow restyles on this testcase

Status: RESOLVED WORKSFORME

(Core :: CSS Parsing and Computation, defect, P3)

Description

[stephen.trigg]

Attachment: jira_schema.html

User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0
Build ID: 20180711184510

Steps to reproduce:

Viewed a web page with a large SVG (attached) which is a very large example SVG.
This svg is a representation of a database schema and is an extreme case for comparison between browsers. 




Actual results:

Rendering of SVG takes ~7 times longer than other browsers. During rendering no canvas is painted, so the browser appears to hang. On a large SVG this can be a very long hang of well over one minute.

Using the same hardware in each case:

on Chrome 68.0.3440.106 the svg renders completely in ~15sec.
on Firefox 61.0.2 the same svg renders in just over 100sec.

Most of that time is spent in "Apply Style Changes" (98.75sec) - approx 0.2ms per element.




Expected results:

Other browsers display the incomplete SVG as it is rendered (removing the apparent hang) and completely render the image in a fraction of the time.

Comment 1

[Daniel Holbert [:dholbert]]

(In reply to stephen.trigg from comment #0)
> on Chrome 68.0.3440.106 the svg renders completely in ~15sec.
> on Firefox 61.0.2 the same svg renders in just over 100sec.

For what it's worth: on my 24-core desktop machine, I'm seeing Firefox Nightly 63 being quite a bit *faster* than Chrome DevEdition 70.  I wonder why I'm seeing the opposite of stephen -- perhaps the "stylo" restyling parallelism is helping on my multicore system but hurting on stephen's system?

Stephen: do you know how many cores your machine has? That would help in tracking down what's going on here.

Also, could you capture a profile of your slow Firefox pageload, using our profiling extension given at https://perf-html.io/ ? (Ctrl Shift 1 to start profiling, which turns the globe icon in your toolbar blue, and Ctrl Shift 2 to capture a profile, and then use "Share" button if you're satisfied with it & want to upload it & get a public URL that you could paste here.)

Here's a profile that I captured in Firefox 63: https://perfht.ml/2w6zdZD
As you can see there, the page is loading in ~10 seconds for me, whereas it takes about ~30 seconds to load in Chrome Dev 70.

Anyway -- my profile does show that restyling is the most expensive part. CC'ing emilio/xidorn in case they have any thoughts.

Comment 2

[Emilio Cobos Álvarez (:emilio)]

Note that I changed how <svg:use> works in bug 1450250, which should make us quite faster here. I'm pretty sure that a build without that patch will make us way slower, since we need to restyle each <use> subtree separately, instead of all at the same time.

It'd also be helpful to see a profile with the sequential styling checkbox checked.

Comment 3

[Emilio Cobos Álvarez (:emilio)]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #2)
> Note that I changed how <svg:use> works in bug 1450250, which should make us
> quite faster here. I'm pretty sure that a build without that patch will make
> us way slower, since we need to restyle each <use> subtree separately,
> instead of all at the same time.
> 
> It'd also be helpful to see a profile with the sequential styling checkbox
> checked.

On nightly, with this: https://perfht.ml/2PtmxnP

Looks like 94% of the time is spent inserting stuff in the rule tree... That looks really bad.

Comment 4

[Emilio Cobos Álvarez (:emilio)]

Ah, I think I know what's going on. We create a unique declaration block for each SVG element with mapped attributes.

Since these elements have no other rules applied, the rule tree ends up with a single node for each tag with a lot of leaves, which is pretty much the worse case for it.

I think we could share them, the same way we share style="" attribute declaration blocks, and this should make this test-case basically instant.

Comment 5

[Emilio Cobos Álvarez (:emilio)]

I looked into this, and turns out to be quite annoying because the key cannot be just text (unless we create a declaration block per attribute, which might or might be ok?), and also because of cross-document <svg:use> (where you have a different base URI).

We could cache them if the base uri, doc uri and principal are the same, or if we don't have potentially url-dependent values. Still it's probably a bunch of work. I filed bug 1485511 for that, but I don't think I could get to it really soon.

Comment 6

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

On my laptop Nightly is faster than Chrome

Comment 7

[Daniel Holbert [:dholbert]]

Stephen: if you're open to trying our Nightly builds from http://nightly.mozilla.org/ , would you mind testing to confirm that this is faster for you as well?  It sounds like bug 1450250 may have improved things quite a bit.

(If you want to be on the safe side, you may want to create a new default Firefox profile at the special URL "about:profiles" before you install Nightly, just to be sure there's no dataloss from switching back and forth between versions.  Unlikely that anything would go wrong, but not impossible.)

And, Emilio: is there more to be done here, beyond what's tracked in bug 1485511?

Comment 8

[Emilio Cobos Álvarez (:emilio)]

(In reply to Daniel Holbert [:dholbert] from comment #7)
> And, Emilio: is there more to be done here, beyond what's tracked in bug
> 1485511?

I don't think so.

Comment 9

[stephen.trigg]

(In reply to Daniel Holbert [:dholbert] from comment #7)
> Stephen: if you're open to trying our Nightly builds from
> http://nightly.mozilla.org/ , would you mind testing to confirm that this is
> faster for you as well?  It sounds like bug 1450250 may have improved things
> quite a bit.
> 
> (If you want to be on the safe side, you may want to create a new default
> Firefox profile at the special URL "about:profiles" before you install
> Nightly, just to be sure there's no dataloss from switching back and forth
> between versions.  Unlikely that anything would go wrong, but not
> impossible.)
> 
> And, Emilio: is there more to be done here, beyond what's tracked in bug
> 1485511?

On the same test machine, using nightly build, the SVG rendered in about 12 seconds - so yeah, faster than chrome. Nice.

Comment 10

[Daniel Holbert [:dholbert]]

Great! Let's call this "worksforme" then (likely fixed by bug 1450250, but fixed in trunk one way or another) -- and we'll use bug 1485511 to track the remaining optimization opportunities that have been identified here.