Extremely slow startup with uBlock Origin #252
Comments
|
uBlock and uBlock Origin are essentially the same core code... Difference at this point is merely UI. What version of uBlock Origin? |
|
|
|
I have the latest versions available from the Firefox add-ons website, which are: uBlock Origin: 0.9.8.1.1 I've noticed this issue ever since I started using uBlock Origin a few weeks ago (I was using uBlock before that). I got sick of waiting for the startup so I switched back to uBlock and the problem disappeared. Then I experimented with uBlock enabled, uBlock Origin and neither enabled and the results were all very consistent (as mentioned above). |
|
I would need to see exactly all your settings, that's not normal. Even 10-15 seconds for uBlock is way more than I would expect. What are your h/w specs? Again, exactly all your settings. |
|
One thing which would be interesting to find out, is the size of the sqlite db used by uBlock. On Windows, it is located at (as per this): |
|
For me the 10-15 seconds is normal, since I have ~530 tabs in tab groups and it takes about that long to load the browser generally (even without addons). The bug report is mainly that uBlock Origin is taking 35-45 seconds (much longer than no plugins, and much longer than uBlock -- both about 10-15 seconds). Basically, uBlock adds no additional overhead to browser startup time, while uBlock Origin adds an additional 20-30 seconds to startup time. My ublock0.sqlite and ublock.sqlite files are both about 9MB in size. For h/w specs: |
|
@jetwhiz Damn, mine's 24.3, so it's most likely not that. |
Ok you've got better specs than mine, and my Firefox starts within one second typically. Since I can't reproduce your scenario, what would help is for you to install prior versions of uBlock Origin and see if there is one which can be identified for the slowness (use "binary search", i.e. install 0.9.6.0, then if issue is there install 0.9.4.0, if not 0.9.7.0 etc. both uBlock are same at 0.9.3.0) If you do so, beware though: with uBlock/uBlock Origin, the first launch is always the slowest, because all filter lists need to be compiled. For subsequent launches, it will be faster because the compiled versions are cached. And when a selfie is available -- which will happen after a few minutes with no change/update to the filters lists -- the launch time will be even faster. As said, uBlock/uBlock origin loading code is still pretty much the same, so to get such a large gap is difficult to explain. |
Not sure what "tab groups" are. Are they tabs with content in them? I mean if you would go to uBlock's logger, would these tabs be reported in the logger's dropdown tab list without having to bring these tabs forth first? (in other words, are they merely some sort of bookmarks until you open them?) |
|
Here is what I get for the different uBlock Origin versions: v0.9.6.0: ~15 seconds (same as no add-ons and uBlock) There is something going on with the 0.9.7.5 version that is causing all kinds of havoc with my browser. Whatever was changed between that and 0.9.8.1.1 helped the issue, but is still much slower than before. For tab groups, they are treated similar to open windows/tabs -- meaning that their sessions are restored when you restart the browser with "Show my windows and tabs from last time" selected in options. |
|
Thanks for taking the time to narrow this. I will code review all the changes between 0.9.7.0 and 0.9.7.5 and see if there is something. |
|
Tab groups can be opened by pressing CTRL + SHIFT + E. There is also a menu button for it in customize menu and if you have overflowing tabs in the tab list dropdown. |
|
Ok, for now the only spot I can see which could be responsible is e0284b8#diff-ce215d94a52d449f1a34f292126608d7, which is code to fetch a tab title. The fact that you launch with over 500 live tabs makes this even more likely to be the issue. (by the way, why not have the tabs load only when you activate them? i.e. "Don’t load tabs until selected") I will see if and what can be improved, but the title fetching is already done in a lazy way in the core code, I suspect the overhead is rather on the platform-dependent code for Firefox. |
|
I do have "Don't load tabs until selected" checked, and none of the tabs load until they are activated (when I focus on their tab). The slow startup in general is mainly because the session is so large (almost 1MB in size), so the fact that all of the tabs exist must be loaded into the browser (along with their session data, etc.). With the session cleared (all of the tabs closed) my browser only takes about 1 second to start. Hopefully this is the issue though ... if you need me to do any other testing just let me know and I'll help out where I can. Thanks for looking into this for me! |
Ok, good to know, I will take this into account for the fix. There might be another area to also revise to help improve launch performance for your case. |
I have to correct myself: the Firefox platform-dependent code is correct, it will mind only the tabs which are not pending, i.e. the tab title code above should not be an issue -- only one tab will be worked on at launch even if 500+ more are pending. In doubt, I d/l Firefox 38.0.5 to see if it worked as expected and it was fine. So now I wonder if the fact that you used "grouped tabs" is how the issue manifest it self. I never used this feature, I will have to understand how this work first. |
|
Kind of back to square one, as I can't see how the tab title code could be an issue. The cause of 0.9.7.5 slow launch could be related to this silly regression bug, fixed in 0.9.8.0. For 0.9.8.1 no being on par with 0.9.7.0, I will have to dig more, I can't think of anything for now. |
|
Well I looked at net changes between 0.9.7.0 and 0.9.8.1 ( Now like all bugs, it comes down to me being able to reproduce. I am nowhere near having access to a set of 500+ grouped tabs. |
|
You might be right about the 0.9.7.5 just being related to the regression, since the browser freezes during loading and the 60+ second startup time could just be explained by that. The thing that is strange to me is the issue doesn't exist in uBlock, even though they are so similar as you've said. Is there an easy way to compare the code between uBlock (latest) and uBlock Origin (0.9.8.1) to see if there's anything there? Are there any plugins or settings I can install that can help to debug the issue and see where the slow startup is coming from? |
|
Did you look if the browser console (ctr-shift-j) says something noteworthy for the pathological case? |
|
I don't see anything that stands out. One surprising thing is that I think Firefox is requesting all of the favicons for my tabs upon browser startup, since I see a bunch of these errors for tabs that aren't activated: This site makes use of a SHA-1 Certificate; it's recommended you use certificates with signature algorithms that use hash functions stronger than SHA-1.[Learn More] favicon.ico Could uBlock be triggering upon favicon request? |
Doubful. I put a breakpoint in the code which is executed at launch to initialize the tabs, and only active tabs were seen by uBlock. Favicons are pulled using behind-the-scene requests. Is it possible these behind-the-scene requests are blocked by uBlock and not uBlock Origin? ( |
|
Not sure if my experience is related ... My Firefox is configured to start with only 1 loaded tab (Google Search), so my FF starts up in 2–3 secs. But since uBlock Origin v 0.9.7.5 (from GitHub) & v 0.9.8.1.1-signed (auto-updated via AMO), my FF has been experiencing relatively sustained spikes in RAM use, as well as periodic spikes in CPU usage (12–15%). During normal browsing (5–8 loaded tabs), my laptop's fan would rev up noticeably as long as uBlock Origin is enabled. It wasn't like this before v 0.9.7.5. When I try uBlock 0.9.4.0 (from GitHub) with identical filter lists, everything behaves as per normal. There is no unexpectedly high RAM usage or periodic CPU spikes, & my laptop fan stays quiet (thankfully). Below shows sample RAM usage (observed at 5 secs interval) as given by
Remarks:-
|
Can you elaborate? |
It's the same core code. I sense with all these statements some new myths in the making. Let's stick to very hard measured data please, I never relied on "computer fan" test to benchmark uBlock against other blockers, only hard objective data which others can replicate. The benchmark which I did come up with I ensure I could replicate them all the times myself first by following the steps I wrote down. It's a whole lot more work, but you can trust you are closer to reality as a result, not fantasy. What you offer is no methodology, there is no way anybody can replicate this, there a lot of factors which would need to be spelled out first, including whether there is a selfie, whether the filter lists are all compiled, whether the update kicks in at exactly the same time in all tests, and whether there are filter lists marked as obsolete, and exactly which URL is open, did you restart Firefox after enabling the add-on, etc. Here is an example of a reproducible benchmark: https://github.com/gorhill/uBlock/wiki/Firefox-version:-benchmarking-memory-footprint. You can try it and you will get the same results. There is way too many missing details in the figures you offer. You need to provide a very detailed step-by-step that anybody else can follow, which is not the case with what you offer. Also, There are a lot of people who thinks Adblock Edge is much more performant than Adblock Plus (acceptable ads disabled), this shows that you can't trust subjectivity, only very rigorous tests. If you come up with something which yourself and others can replicate, with exact steps and all relevant configuration details, that is usable, short of this is to wander in myth-making realm. |
|
@gorhill — A few sub-versions ago, I recall reading something to effect in Here it is ...
Did I wrongly interpret the last segment wrongly (highlighted in bold above) ? Incidentally, I have this uBlock Origin toolbar badge notification-displacement since v 0.9.4.3 (mid-April 2015). Sometime after reading your Nevertheless, I continued with uBlock Origin until 0.9.7.0. It was v 0.9.7.5 onwards (high RAM use) that made FF & my laptop not so conducive to use. |
Yes. You said:
It was never fully compatible. Full support for legacy FF was added to uBlock after the fork, and that full support was a UI thing, to have a button showing on the toolbar -- FF legacy versions were missing that button. |
Yes, I am pretty sure this was because of the regression bug pointed out above. This has been fixed in 0.9.8.0. As said, I diff'ed 0.9.7.0 with 0.9.8.0, and if you leave out translation work and other unimportant UI stuff, there is nothing in core code which can support that uBlock Origin performs worst than uBlock. There is not many changes really in the core code, anyone can check: |
You could put a break point into uBlock to validate that all these tabs are seen as being active by uBlock, which would explain the longer boot time. The line to which a breakpoint must be set is: uBlock/platform/firefox/vapi-background.js Line 2047 in c285ace At this point, uBlock is fully loaded, and it's finding out which tabs are active, and for all active tabs, it will inject its content scripts + other housekeeping stuff (thus overhead). If ever it is really going through all the tabs (i.e. the |
|
@gorhill — Thanks for your advice & explanations. I wasn't aware that However though, I wasn't really trying to benchmark uBlock Origin vs. uBlock per se. I'm more interested in how uBlock Origin has been evolving, & what actions I should take to adapt to uO's growth.
My FF is 32-bit. So I'm not familiar with how uBlock behaves in 64-bit FF.
Tks for the info. Might it be good to put a note somewhere to indicate the FF versions (or the lowest FF version) that are fully-compatible with uO ? For instance, many add-ons provide such info at AMO, & I personally find that helpful. As an end-user with no IT training, I don't expect or insist that my own user experience (or even awkward informal tests) necessarily extrapolate to other users. This is the 1st time that I'd ever mentioned high RAM use as of v 0.9.7.5. (I shall continue to monitor, since you reported that this has been resolved.) Moreover, I have never discussed uO issues except at this GitHub page, where you can monitor & quickly dispel user errors or unintentional misconceptions — which in this case, unfortunately appear like "new myths in the making" ... & I'm glad you stopped the oven. :) I hope that this clarifies. Thanks ! |
|
I wish -- it would be a quick explanation -- but uBlock and uBlock Origin both have behind-the-scene set. I didn't customize anything in either addon except for the filter lists (and they both have the same filters selected). |
|
Can you test dev release? Some work has been done to fix #266, and there is good chance the slowness here is related to the same underlying issue. |
|
No feedback for more than two weeks, I will assume that in all likelihood it was related to #266. |
|
I have the same problem. I even did a clean chrome install and also new origin install. Without the addon my browser doesnt hang at startup. With addon enabled i cant to anything for almost a minute, like op said. |
|
@ShadowDuke you provide no actionable information. I can't reproduce your described behavior. There is likely something else specific on your side causing this, quite probably unrelated to uBO. You will have to investigate yourself and provide useful and actionable information if you make the case the issue is with uBO. Use the Gecko profiler to find out whether uBO is behind your slow down, that is the only way to move your issue forward. uBO makes use of indexedDB, so see if removing/reinstalling uBO (restarts the browser in between) solves your issue, I suppose it's possible a corrupted indexedDB may be causing all sort of negative issues (don't forget to back up your settings before un-installing). |
When starting my browser without uBlock Origin enabled (and no ad blocking software at all) my browser is ready to go in about 10 - 15 seconds, however with uBlock Origin enabled it takes around 35 - 45 seconds (with the same settings and tabs open).
When I try this with uBlock instead of uBlock Origin the browser is ready in 10 - 15 seconds (the same as with no ad blocking software at all). This is with the same filters set for both uBlock and uBlock Origin. It seems something specific to uBlock Origin that is taking a very long time to load that does not exist in uBlock.
During the 35 - 45 seconds of waiting with uBlock Origin, Firefox is using ~15% processing power consistently. This is on a Windows 8.1 machine with Firefox 38.0.5 (latest).
The text was updated successfully, but these errors were encountered: