Closed Bug 1582990 Opened 5 years ago Closed 4 years ago

WebExtension Performance Regression (uBO, ABP)

Categories

(Core :: Performance, defect, P1)

69 Branch
defect

Tracking

()

RESOLVED WORKSFORME
Performance Impact high

People

(Reporter: jmbates, Assigned: sefeng)

Details

(5 keywords)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0

Steps to reproduce:

In Firefox (70b8 or 69.0.1), with a new browser profile, with only uBlock Origin installed, there is a severe rendering delay when compared against uBlock Origin not being installed.

https://en.wikipedia.org/wiki/Link_Layer_Discovery_Protocol

  • Install Firefox 69.0.1
  • Load the above page and measure dom / load time
  • Install uBlock Origin
  • Load the above page and measure dom / load time
  • Compare results

Performance profiles:

Without uBO:
https://perfht.ml/2OfRlui

With uBO only:
https://perfht.ml/2OoFM43

With ABP only (extra data point):
https://perfht.ml/2OgWcen

Looking at the above findings, notice the "Waiting for Socket Thread" and other network statuses. Not sure if this is a red herring. Also, there is a large performance difference regardless of whether the resources are cached (confirmed using dev-tools disable cache)

Please see the following Issue thread on github relating to uBO for some extra context:

https://github.com/uBlockOrigin/uBlock-issues/issues/729

Actual results:

The page load time was substantially longer with uBO / ABP installed than without them installed

Expected results:

Page load time should not suffer this much from a performance perspective

Links were backwards, now corrected:

Without uBO:
https://perfht.ml/2OoFM43

With uBO only:
https://perfht.ml/2OfRlui

With ABP only (extra data point):
https://perfht.ml/2OgWcen

Severity: normal → critical
Component: Untriaged → Performance
Product: Firefox → Core
Status: UNCONFIRMED → NEW
Has Regression Range: --- → no
Has STR: --- → yes
Ever confirmed: true
Priority: -- → P1
Whiteboard: qf:p1:pageload

Hy there, was trying to get a regression range check for this issue.
To ensure that we're on the right track, what options need to be enabled for the profiler for the same reading as in the links?

Also, does it still reproduce? Since there wasn't something noticeable on the attempts I had at it.
Thanks in advance!

Flags: needinfo?(jmbates)

Honza, do you think this is similar to bug 1567863?

Flags: needinfo?(honzab.moz)

Can't say neither yes or no. Could be, but I really don't see anything that could be interpreted somehow in the profiles. Note that bug 1567863 is reproduced on a very slow machine, not sure what hardware is here (according the profile w/o ubo it seems fast).

I don't have a try build with BT included to try this time. When I have one available, we can check with that.

Going to try reproduce it on both Low-end and high-end devices.

Flags: needinfo?(sefeng)
Assignee: nobody → sefeng

I am unable to reproduce it on a high-end Linux machine and a low-end Windows machine.

Flags: needinfo?(sefeng)

Hi, jmbates

Is this issue still reproducible in Firefox 71?

Do you mind capture a new profile for more threads? Just put , as the custom thread name, and it will capture all threads.

Thanks

@jmbates: Could you please answer to comment 2 and comment 7?
Thank you for your contribution!

Closing the issue since we cannot reproduce.
Due to lack of response, we can only assume that the issue is no longer reproducible on the side of the reporter.

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WORKSFORME
Flags: needinfo?(honzab.moz)
Flags: needinfo?(jmbates)
Performance Impact: --- → P1
Keywords: perf:pageload
Whiteboard: qf:p1:pageload
You need to log in before you can comment on or make changes to this bug.