1405899 - stylo: Element::Matches using stylo is slower than using Gecko in some cases

Status: RESOLVED WORKSFORME

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

Description

[Boris Zbarsky [:bzbarsky]]

Attachment: Testcase

See attached testcase.  The "html body" selector is noticeably (10-20%) slower with layout.css.servo.enabled set to true.

I didn't test more complicated selectors yet.

Comment 1

[Boris Zbarsky [:bzbarsky]]

57 is not affected, because bug 1404897 is 58-only and I assume we don't plan to backport it to 57.

Comment 2

[Boris Zbarsky [:bzbarsky]]

So just looking at the "html body" selector, a Gecko profile is https://perfht.ml/2xiT8SS and a Stylo profile is https://perfht.ml/2xiBRt4

The main difference is that Stylo seems to spend about 33ms in self time in matches_complex_selector_internal (and another 6ms in matches_complex_selector) while the corresponding time for Gecko (SelectorMatchesTree) seems to be about 8ms.  That's not quite right, because parts of matches_complex_selector are inside SelectorMatches in Gecko (which really matches a sequence of simple selectors), but the SelectorMatches calls are comparable in time spent to the matches_simple_selector calls in Stylo...

Sadly, I can't get per-line blame with the gecko profiler.

Comment 3

[Emilio Cobos Álvarez (:emilio)]

I can't repro this Boris. With stylo enabled I get times that look like:

81.97500000000002
69.94999999999999
95.445

With stylo disabled I get times that look like:

101.22500000000002
90.12500000000006
127.005

There's a bit of noise, but stylo numbers look quite better than Gecko's overall.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Hmm.  I tried a build from our infra and I'm getting numbers that are a lot better than my local optimized build.  All this on Mac.

Let me try updating rustc to 1.20 and seeing whether that changes things...

Comment 5

[Boris Zbarsky [:bzbarsky]]

I'm getting numbers like I was getting before, with rustc 1.20 and local builds.  Specifically:

Stylo enabled:
84.58
81.56500000000001
125.69999999999999

Stylo disabled:
88.72
73.215
98.13499999999999

With the m-c build I downloaded, I get:

Stylo enabled:
80.755
66.865
95.61499999999998

Stylo disabled:
82.13
73.74
98.10500000000002

Comment 6

[Kacper Michajłow [:kasper93]]

Performance regression is quite terrible in certain cases, it is multiple times slower. Please take a look at this comment https://github.com/gorhill/uBlock/issues/3111#issuecomment-335918101 it contains link to the NSFW that is unusable with uBlock Origin after switch to Stylo for Element::Matches. I confirmed that disabling Stylo bring back proper performance. Please tell me if you can reproduce if not I will prepare standalone testcase. But you should be able to reproduce easily, try scrolling page...

Comment 7

[Emilio Cobos Álvarez (:emilio)]

(In reply to Kacper Michajłow [:kasper93] from comment #6)
> Performance regression is quite terrible in certain cases, it is multiple
> times slower. Please take a look at this comment
> https://github.com/gorhill/uBlock/issues/3111#issuecomment-335918101 it
> contains link to the NSFW that is unusable with uBlock Origin after switch
> to Stylo for Element::Matches. I confirmed that disabling Stylo bring back
> proper performance. Please tell me if you can reproduce if not I will
> prepare standalone testcase. But you should be able to reproduce easily, try
> scrolling page...

Do you have a selector for that / a test-case? I can look into this tomorrow installing uBlock myself too.

Thanks for reaching out!

Comment 8

[Emilio Cobos Álvarez (:emilio)]

(Just pointing me to where the selectors that page is testing are defined may save me some time tomorrow, but I definitely plan to look into this)

Comment 9

[gwarser]

I also tried to reproduce on SFW page.
Using Nightly 20171011100133, uBlock Origin 1.14.14 with default settings plus "--- Banner sizes ---" section (250 generic filters) from "Adguard Base Filters"[1] copied into My Filters tab in uBlock settings (may be easier to just enable "Adguard Base Filters" in 3rd-party filters tab)
Open https://discourse.mozilla.org/
Start profiling
Refresh page.
Stop after fully loaded.

On my system,
with `layout.css.servo.enabled;false` processHighHighGeneric[2] takes 435ms - https://perfht.ml/2ycJLJj
with `layout.css.servo.enabled;true` - 5105ms - https://perfht.ml/2ybW2NQ`

[1]:https://filters.adtidy.org/extension/ublock/filters/2_without_easylist.txt
[2]:https://github.com/gorhill/uBlock/blob/master/src/js/contentscript.js?utf8=%E2%9C%93#L1460

Comment 10

[Boris Zbarsky [:bzbarsky]]

I filed bug 1407864 on the uBlock Origin issue from comment 6 and comment 9.  Thank you for the profiles!  They made this really easy to diagnose.

I'd like to keep this bug focused on the problem I was seeing, which is a much smaller and subtler (and maybe limited to my self-builds?) effect.

Comment 11

[Emilio Cobos Álvarez (:emilio)]

This is now considerably _faster_ with Stylo enabled on the current nightly. Part of it may be because the old style system is already not exercised by PGO I presume...

Thinking through, I don't know if the measurements of the local opt builds mentioned in comment 5 may be because the default rust opt level for opt is 1 instead of 2, but not sure...

Anyway I don't think there's anything actionable here right now. I'm trying to land PGO support in rust this month, that may make this even faster on Stylo.