1.22.2 Firefox Performance regression

[errantmind]

Prerequisites

• I verified that this is not a filter issue
  • Filter issues MUST be reported at filter issue tracker
• This is not a support issue or a question
  • Support issues and questions are handled at /r/uBlockOrigin
• I performed a cursory search of the issue tracker to avoid opening a duplicate issue
  • Your issue may already be reported.
• I tried to reproduce the issue when...
  • uBlock Origin is the only extension
  • uBlock Origin with default lists/settings
  • using a new, unmodified browser profile
• I am running the latest version of uBlock Origin
• I checked the documentation to understand that the issue I report is not a normal behavior

Description

Performance regression. In Firefox (70b8 or 69.0.1), with a new browser profile, with only uBlock Origin installed, with the 'big button' turned off, with no filter lists selected, there is a severe rendering delay when compared against uBlock Origin not being installed.

Please see the before and after screenshots here and here respectively. Yes, I am using an addon to show some details but the same results are present when using dev-tools.

A specific URL where the issue occurs

here

Steps to Reproduce

1. Install Firefox 69.0.1
2. Load the above page and measure dom / load time
3. Install uBlock Origin
4. Keep it enabled or disable it on the above site using the big button (same result either way)
5. Load the above page and measure dom / load time
6. Compare results

Expected behavior:

Comparison with uBlock Origin turned off on site should show very little difference in before / after load time

Actual behavior:

Large difference in load time (73ms vs 1.81s)

Your environment

• uBlock Origin version: 1.22.2
• Browser Name and version: Firefox 69.0.1
• Operating System and version: Windows 10 1809

[gorhill]

Use the Firefox profiler to substantiate claimed performance issues as demanded in the template, not screenshots of an unnamed extension of unknown origin

[gorhill]

1.21.2: https://profiler.firefox.com/public/4c3ebd5966c2309882a1896b512e7cfd6c9e5c2f/calltree/?globalTrackOrder=0-1-2&implementation=js&localTrackOrderByPid=12198-0~12561-0~&search=moz-&thread=2&v=4

1.22.2: https://profiler.firefox.com/public/2ad03a9575e37872b44613a11b9c111dd6f4e711/calltree/?globalTrackOrder=0-1-2&implementation=js&localTrackOrderByPid=12198-0~12292-0~&search=moz-&thread=2&v=4

uBO is virtually a noop on that Wikipedia page and there is no difference between 1.21.2 and 1.22.2.

Re-open when you have actual profiling data as requested in the template you filled to substantiate your claim of performance issue.

[uBlock-user]

Speculated performance issues will be marked as invalid and closed if they do not come with actual profiling data from Firefox Profiler + analysis supporting the claim.

[gorhill]

Looks like he used this extension: https://addons.mozilla.org/en-CA/firefox/addon/load-time/ (for whoever wants to try it) -- this should have been disclosed in the steps-to-reproduce.

From the results shown in his screenshots, the slowness came from the loading of subresources, something completely dependent on network conditions -- i.e. this is an invalid way to draw conclusion regarding the performance of JavaScript.

[errantmind]

Happy to collect some more data. Please see the profile with ubo, times 0.996 -> ? and without ubo, times 47.158 -> ?. I don't know enough about the browser to clearly identify the 'end time' so I used question marks.

A couple of thoughts:

1. I did mention I used an addon (Load-Time) and also said it is the same without the addon using only the dev tools
2. This issue isn't specific to 1.22.2 as far as I know, I emphasized the version for reference only
3. I see this issue on two different computers, with new profiles, where the only difference is ubo being installed or not

[gorhill]

Those profiling results are invalid:

• uBO is nowhere to be seen in the results
• There is no WebExtensions process, where uBO reside
• There is no WebContent process, where the web page resides

There is only one single Parent process and JavaScript is reported as running only single-digit milliseconds in there.

[errantmind]

I could record my screen to prove uBO is enabled / disabled but I'm not sure this would convince you. Have you tried replicating my results in Firefox 69? Do you have those processes in your performance profile? When I compare my results, the main event which stands out is an excessive amount of RefreshDriverTick in the "with uBO" profile.

[gorhill]

Have you tried replicating my results in Firefox 69?

I have posted two profiling results. Notice how your profiling results are devoid of any useful information -- they show nothing. Just provide usable profiling results like I did above.

[errantmind]

Can you screenshot your profiler settings to show me what you need to be enabled / recorded and published? I'm a bit new to doing this so any info you can provide will help me out

[gorhill]

Click the links to the profiling results I posted above. You can see:

• Parent process (when browser's chrome resides)
• WebExtensions process (where uBO resides)
• Web Content process (where the web page resides)

uBO is written in JavaScript, profiling results which do not show it's JavaScript execution in the Web Content and WebExtensions process are useless, they can't be used to prove or disprove anything.

When you publish profiling results, do not filter out items which are key to prove or disprove your claim of performance issues.

[errantmind]

How about this? with uBO, without

[gorhill]

It looks better -- WebExtensions/Web Content are in there. Give me time to see what I can find in there.

[gwarser]

"Waiting for socket thread"

https://bugzilla.mozilla.org/show_bug.cgi?id=1560697

[gorhill]

I think Firefox developers need to look into this, they are better placed than I am to find out what is happening in there.

To be clear, uBO uses just 11ms in the WebExtensions process, and 2ms in the WebContent process, so uBO's JavaScript is not the issue here (you can filter the output by clicking "JavaScript" and further filter out using "moz-" in the "Filter stacks" field.)

Best is to report these profiling results to Firefox devs, I don't know what to make of these -- what I can tell is that uBO's JavaScript timings are not the reason causing your performance issue, uBO's JavaScript would show in a prominent manner if it was the case.

As far as I can tell, it seems most threads are mostly idle and waiting for something.

[gorhill]

@gwarser But according to repro steps and details given in opening comment, this was not a case of browser launch issue.

[gwarser]

Click black bar in content process (DocumentLoad). Loading part will be selected. Switch to network tab. Every network request spends most of time in "Waiting for socket thread".

[gorhill]

For the images it does not wait for socket thread but still take an undue amount of time to load.

Also I note that @errantmind checked "using a new, unmodified browser profile", which mean https://bugzilla.mozilla.org/show_bug.cgi?id=1560697 shouldn't affect him in the new profile?

[errantmind]

Yes, I installed Firefox 69 and did the above tests. I also created a new profile using about:profiles and did the same tests and got the same results

[gorhill]

It's best you report to Firefox devs, since it appears you discovered a new case of "waiting for socket thread". Also did you try with another extension than uBO, similarly purposed?

[errantmind]

I just tried it with ABP and got similar results. I'll enter a bug over on bugzilla

[errantmind]

For reference: https://bugzilla.mozilla.org/show_bug.cgi?id=1582990