1428573 - Startup performance impact of uBlock Origin and HTTPS Everywhere

Status: RESOLVED INCOMPLETE

(Firefox for Android Graveyard :: General, defect, P5)

Description

[Jan Henning [:JanH]]

Attachment: startup timings add-ons.xlsx

(In reply to bull500 from bug 1420641 comment #47)
> Does anybody else here use the HTTPS everywhere addon?? It seems to make the
> load times much worse than before.

Using a fresh profile with Nightly (2018-01-04) and purely looking at the zerdatime logcat startup timings, you get values for application start, runGecko, chrome startup finished and two sets of page load start and stop. The first page load is an artifact of session restore, immediately aborted again and in any case not really influenced by the presence of add-ons, so looking at the second, proper page load, with ten samples each I see the following results:

No add-ons: ~5.1 seconds
only Stylus: ~5.5 seconds
only uBlock Origin: ~8.0 seconds
only HTTPS Everywhere: ~11.9 seconds, but with three outliers taking around 18 seconds (the remaining values have an average of ~9.5 seconds)
uBlock+HTTPS Everywhere: ~12.1 seconds

The timing between runGecko and chrome startup also varies slightly:
No add-ons: ~1.8 seconds
only Stylus: ~1.9 seconds
only uBlock Origin: ~2.0 seconds
only HTTPS Everywhere: ~1.9 seconds
uBlock+HTTPS Everywhere: ~2.1 seconds

In all cases I simply installed the add-on directly from AMO and didn't touch any further configuration options.

I don't have the precise timings for the phases of the page load itself, however from watching the loading indicator, my impression is that the major impact of uBlock/HTTPS Everywhere happens when the progress bar reaches 80 %, i.e. after DOMContentLoaded has fired.

Given that those are probably relatively popular add-ons (especially uBlock), it might be interesting to take a closer look what happens using the profiler, provided somebody can get it to work.

Comment 1

[Jan Henning [:JanH]]

Somehow that got lost while revising the text...
the page I had open was https://www.behance.net/gallery/3209865/Shaun-the-Sheep-Series-II-Storyboards and I should also note especially for the case without uBlock that my phone also has DNS/host file-level adblocking via AdAway active.

Comment 2

[Jan Henning [:JanH]]

Another page that exhibits this effect on my phone is https://m.heise.de

@Raymond/Bill
Not sure in how far you need/want to do something right now, but I guess you might at least be interested to know about this.

Comment 3

[[e-mail]]

One thing to consider is the state of uBO in those benchmarks. Let's assume default filter lists/settings.

Things done at start up depending on uBO's state:

First install state (downloading, parsing = slow loading):
- All filter lists need to be parsed and result of parsing is saved (aka "compiled")
- Possible downloading from remote servers necessary.
- Reading/writing to storage necessary.

Without-selfie state (load from pre-parsed data = fast loading):
- Load all compiled filter lists, scan them, and create data structures from this.
- No download.
- No writing to storage.

With selfie state (load from memory snapshot = very fast loading):
- Load (conceptual equivalent of) memory snapshot from storage
- No download.
- No writing to storage.

I consider the "with selfie" case to be the natural state of uBO, even more so on mobile because I am pretty sure people are less likely to fiddle with filters and configuration settings, which would cause an existing selfie to be destroyed. So it's safe to assume uBO is typically is with a valid selfie.

A selfie is created after a few minutes has elapsed where no change in filter lists/settings occurred.

So first thing would be to find out in what state uBO was in the benchmark. Then from there I would be curious as to where uBO spend most of its time. I am unfortunately not equipped to profile on Firefox for Android with an external profiler.

I did try the internal one using the ADB Helper add-on, but what I get does not seem to point at anything -- if anything it confirms uBO loading from its selfie is fast (see attached pic). My profiling session was simply to enable uBO though (the part selected in the pic), so no web page was loaded at the same time.

Comment 4

[[e-mail]]

Attachment: Built-in profiling: just enable uBO

Comment 5

[Jan Henning [:JanH]]

(In reply to [e-mail] from comment #3)
> I consider the "with selfie" case to be the natural state of uBO, even more
> so on mobile because I am pretty sure people are less likely to fiddle with
> filters and configuration settings, which would cause an existing selfie to
> be destroyed. So it's safe to assume uBO is typically is with a valid selfie.

Good point about this. Is there some way of verifying the presence of the selfie data?

However in any case I did another test run where I'd left uBlock enabled and Firefox running for some time before measuring and only disabled uBlock in the second half of the test run. I also think that the overhead might rather be some page-specific processing going on, because the overhead of enabling is noticeably less when using a simpler page for testing.

E.g. for https://m.heise.de the results were 3.5 (without uBlock) vs. 6.0 seconds (with uBlock), while on http://www.hirezfox.com/km/co/co1024/d/20180105.html, the difference in page load time was only 1.4 (without) vs. 1.9 (with) seconds.

@Jim:
What patches did you use for enabling startup profiling in bug 1420641 and more importantly, how can I use the resulting file given that I can't seem to load it in neither the dev tool profiler nor perf-html.io?

Comment 6

[[e-mail]]

> might rather be some page-specific processing going on

Do you have generic cosmetic filtering enabled? It is disabled by default on Firefox for Android because of the overhead it adds to page load (the overhead depends on the complexity of the page). The option is at the top of "3rd-party filters" pane in the dashboard.

But then writing this, I now do wonder if uBO could be in a specific state at launch time that it does act as if generic cosmetic filtering is enabled -- because it would not yet have retrieved the user settings to tell it that it should not try to enforce generic cosmetic filters.

In any case, I will use the built-in profiler to see what comes out of it when I load the pages in your test case, with and without generic cosmetic filtering.

Comment 7

[Jan Henning [:JanH]]

(In reply to [e-mail] from comment #6)
> > might rather be some page-specific processing going on
> 
> Do you have generic cosmetic filtering enabled? It is disabled by default on
> Firefox for Android because of the overhead it adds to page load (the
> overhead depends on the complexity of the page). The option is at the top of
> "3rd-party filters" pane in the dashboard.

Is it? I've cleared my Nightly profile once again and installed a fresh copy of uBlock Origin (1.14.22) from AMO. Within the settings, "Parse and enforce cosmetic filters" is enabled and "Ignore generic cosmetic filters" isn't.

Comment 8

[(inactive) Jim Chen [:jchen] [:darchons]]

The changeset on try is at https://hg.mozilla.org/try/pushloghtml?changeset=07f61e49a387, but you have to go back a few changesets to see all the revs. The patches basically enable startup profiling and add a tracing mode to the profiler.

I should look at why it doesn't load in perf-html. For looking at the tracing data, you can use https://moz.jnchen.com/traceview, which is built from https://github.com/darchons/gecko-traceview

Comment 9

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Nice find, Jan.

[triage] Popular add-ons cause significant startup regression (includes a page load?). Before working on this, we should get the number of installs of these add-ons to determine if it's worth fixing.

Comment 10

[:sdaswani]

Andreas, do you have install rates for add-ons somewhere?

Comment 11

[Andreas Bovens [:abovens]]

Sorry for the late follow up. Pinging Mike to see if we have mobile add-ons install rates.

Comment 12

[Mike Conca [:mconca]]

We do have mobile add-on install rates, I can provide a list separately. For uBO, the Android version has approximately 350K users.  This easily puts it into the top tier of mobile add-ons.

Comment 13

[Firefox Bug Husbandry Bot]

Re-triaging per https://bugzilla.mozilla.org/show_bug.cgi?id=1473195

Needinfo :susheel if you think this bug should be re-triaged.

Comment 14

[BMO Automation]

We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.