[Firefox] Slow startup when compared to AdBlock Plus

[ekerazha]

When you start Firefox, by default the "about:home" page is loaded.

• No adblock: the "about:home" page loads fast
• AdBlock Plus: the "about:home" page loads fast
• uBlock: the "about:home" page loads after a longer-than-normal delay (meanwhile a blank page is shown)

ABP and uBlock use the same lists.

This only happens when I start Firefox, if I open "about:home" afterwards it loads fast.

I didn't try other home page URLs, just about:home.

[gorhill]

Some observations:

• This is true when uBlock has no valid selfie (if given enough time, a selfie is made not too long after launch)

Now that said, here is another case to test:

• Enter "buy iphone" in Google search: see results with no ads (ABP or uBlock)
• Close all tabs and leave this one as the only tab opened (instead of about:home)
• Launch with uBlock only: no ads
• Launch with ABP: ads, which disappear seconds after page shows

So it appears ABP is delaying the loading of its filters. However, this results in many unhappy users.

For uBlock, I do not feel the need to delay loading the filters because:

1. it's relatively fast
2. once a selfie is made, there won't be noticeable delay

And in both cases whatever ads will be blocked just fine on whatever tab is opened.

So the delay will go away as soon as uBlock makes a selfie of itself. More about this here.

Still, I have been thinking about further improving the loading/parsing of filter lists lately, and there might be some ideas which are worth exploring in the medium term.

[harshanvn]

Also, it is important to note that the startup time may vary on many other factors like...

• what other operations is being done by CPU
• Having many addons
• Condition of firefox profile.

Here is quick rundown of startup times, not sure if a selfie is a created here or not...(captured in ms, from health report)

run 1:below, opened 3 times (disabled uBlock,no addon) 1595, 853, 1071 run 2:below, opened 3 times (enabled uBlock) 839, 996, 889 run 3:below, below opened 4 times (disabled uBlock, no Addons) 867, 968, 830, 819 run 4:below, below opened 5 times (enabled uBlock) 864, 1019, 902, 894, 888

Personally i don't mind in delaying for another second or two, instead of slipping the ads and other when sites are loaded during start up.

What the important thing here is, it should not hinder the loading performance in anyway, which uBlock does it best than anything else :+1: And happy to be back as a firefox user :)

[gorhill]

Where did you get these numbers? They are ms I presume? Why is there more than one figure? Is it multiple measurements for the measured scenario?

[harshanvn]

Yes. Each number denotes one start up time. So, 3-4 times i did started the browser and repeated it 4 tmes. Path: about:healthreport --> Select Raw Data, JSON format ( search with "firstpaint", you should the see time stamps as milli seconds listed by "days")

[ekerazha]

At the moment uBlock doesn't slow down the home page loading anymore, maybe it uses the "selfie" now. However the slowdown was subtle but annoying when I installed the extension.

[ghost]

As gorhill pointed out, ABP, as of recently, loads filters after start up. On the systems I use, this helped the start up time, but makes the browser unresponsive for a few seconds. Not to mention the loss of blocking which is annoying if someone uses another website for home page besides about:home.

Adguard behaves in a similar fashion, appears to delay loading.

In other words, placebo.

Both sides of startup should be critically explored. There is no free lunch.

[gorhill]

the slowdown was subtle but annoying when I installed the extension

That's the thing, no free lunch: we have to choose between instant load or not blocking ads on already opened tab.

ABP chose instant load/delayed blocking, I will go with delayed load/instant blocking, given that eventually it will be instant load/instant blocking once a selfie is present.

I will still want to look into improving further the load performance though.

[gorhill]

I think I will work on these load speed improvement ideas, they look more and more attractive to me, and they take care of one aspect of the selfie which bothers me a lot: a selfie is a all or nothing solution, i.e. uBlock loads virtually instantly when there is a selfie, or delayed when there is no selfie. Simply adding a single custom filter invalidate the whole selfie. This bothers me.

I have in mind a solution that is more granular, and which can produce immediate results after the first install, and depending on result, maybe good enough to remove the need for selfie code.

[gorhill]

To give a different perspective on the "Slow startup when compared to AdBlock Plus" statement:

https://www.youtube.com/watch?v=BpypOeK10N8

[gorhill]

Related: #498.

[gorhill]

This is just dev notes for myself.

Default filter lists.

Network filters:

• Pure hostname: 35,101
• Token offset at 0: 21
• Token offset at 0 / specific hostname: 2897
• Token offset at 1: 8593
• Token offset at 1 / specific hostname: 248
• Token offset > 1: 337
• Token offset > 1 / specific hostname: 19
• Left anchored: 5
• Left anchored / specific hostname: 53
• Right anchored: 100
• Right anchored / specific hostname: 23
• Hostname anchored: 7572
• One wildcard / token offset at 0: 2792
• One wildcard / token offset at 0 / specific hostname: 786
• One wildcard / token offset > 1: 137
• One wildcard / specific hostname: 42
• One wildcard left-anchored: 1
• One wildcard left-anchored / specific hostname: 14
• One wildcard right-anchored: 12
• One wildcard right-anchored / specific hostname: 5
• Two or more wildcard: 97
• Two or more wildcard / specific domain: 69
• Regex: 4
• Regex / specific hostname: 68

Cosmetic filters:

• Entity-based hide: 44
• Hostname-based hide: 19387
• Hostname-based exception: 982
• High-high generic hide: 37
• high-medium generic hide: 178
• Low generic hide: 14889

[gorhill]

Edit: New, more realistic benchmarks available at the bottom, now measuring timings for real browser launch, as opposed to merely disabling/enabling the extension. Also, only one "New tab" page is now used (I don't think this was the case here).

[gorhill]

Edit: New, more realistic benchmarks available at the bottom, now measuring timings for real browser launch, as opposed to merely disabling/enabling the extension. Also, only one "New tab" page is now used (I don't think this was the case here).

---

This improvement will also benefit when filter lists have to be reloaded for various other reasons than just at launch: for example, changing selection of filter lists, modifying custom filters, reload following the auto-update of filter lists (the compilation will occur when the new version is received, not when the reload occurs).

Bottom line, if there is a compiled version of a filter list, it loads faster. The cost of compiling a filter list is paid once, when the filter list is written to, and this cost is fully paid back starting at the second reload of the same filter list.

[AlexVallat]

I'm quite curious as to why Firefox is slower than Chromium in these tests - could you share what you are using for the benchmarking? Is it just logging a timestamp before and after µBlock.load(); in start.js?

[gorhill]

https://github.com/gorhill/uBlock/blob/master/src/js/profiler.js

I wrap all the code in start.js:

// Load all: executed once.

(function() {

quickProfiler.start('start.js');

Then in onAllReady(), before vAPI.onLoadAllCompleted():

quickProfiler.stop(0);

[gorhill]

@chrisaljoudi can we change the storage quota on Safari to be more in line with the one for Firefox? (~100 MB). Just to err on the safe side.

[chrisaljoudi]

@gorhill done in ed5891d876.

[gorhill]

Going to be running realistic benchmarks, i.e. really launching the browsers, as opposed to merely disabling/enabling the extension.

[chrisaljoudi]

@gorhill just as an interesting datapoint, with 0.8.8.5-dev, the average of 10 samples on Safari is 207ms.

[gorhill]

@chrisaljoudi The figures have to come from the same system to be able to compare them. Also, did you ensure that it's not the selfie which was loading? I made sure this was not the case with a breakpoint or a console message before starting to collect timing figures.

[chrisaljoudi]

@gorhill yep, I understand and you're obviously right about the figures having to come from the same system.

As far as the selfie goes, yes — I clear vAPI.storage every time.

I only wanted to share the figure because it was interesting, not for precise statistical significance.

[gorhill]

What's your system specs?

[chrisaljoudi]

@gorhill

2GHz Intel Core i7 8GB 1600MHz RAM 256GB SSD

[gorhill]

@chrisaljoudi 207 ms is quite fast. If ever you also measure the timings for 0.8.8.3, I will include it in the tables with a note about different system. If you checkout 0.8.8.3, you will have to add the code for profiling in start.js.

[gorhill]

I think I see why Safari is so fast compared to FF/Chromium: it's vAPI.storage.get is synchronous, whereas it is async in FF/Chromium.

[chrisaljoudi]

@gorhill 331 ms with 0.8.8.3.

And yes, I think you're right about it being vAPI.storage.get.

[gorhill]

I am going to try one last thing to improve launch, somewhat trivial: reduce number of async calls at launch, waiting for data.

[gorhill]

Timings to complete start.js (avg of 10 samples), in ms:

• No other extension
• Two tabs opened:
  • Extension tab
  • New tab (active at launch)
• Factory settings

Chromium 0.8.8.3	Chromium 0.8.8.5-dev	Chromium with selfie	Firefox 0.8.8.3	Firefox 0.8.8.5-dev	Firefox with selfie
810	664	476	878	498	204
	-18%			-43%

Safari, benchmarked on a different rig:

Safari 0.8.8.3	Safari 0.8.8.5-dev
331	207
	-37%

Timings for reloading all default filter lists (avg of 10 samples), in ms:

• Toggling off/on cosmetic filters
  • Taking the timing after turning back on
• Default filter lists

Chromium 0.8.8.3	Chromium 0.8.8.5-dev	Firefox 0.8.8.3	Firefox 0.8.8.5-dev
485	286	481	311
	-41%		-35%

[AlexVallat]

Nice! It may only be fractions of a second, but it's the principle of the thing.