Opened 6 months ago

Closed 6 months ago

Last modified 5 months ago

#5284 closed defect (duplicate)

ABP causes big lags and makes Mozilla Firefox 53 very slow

Reported by: mariusica77 Assignee:
Priority: Unknown Milestone:
Module: Unknown Keywords:
Cc: trev, mapx, arthur Blocked By:
Blocking: Platform: Firefox
Ready: no Confidential: no
Tester: Unknown Verified working: no
Review URL(s):

Description

Environment

Win 10 Home (up-to-date)
Mozilla Firefox 53.0.3
Adblock Plus 2.9
Filters: Adblock Warning Removal List, EasyList, EasyPrivacy, Malware Domains

How to reproduce

  1. Go to e.g. https://netflix.com/
  2. Attempt to scroll thru the home page

Observed behaviour

Images load slow, everything lags, whole browser becomes blocked until I close the tab.
While Netflix homepage is unusable, other sites are affected by slowness (Twitter, YouTube, etc) and it's very slow to scroll in them. Clicking on links or videos is also slow until mouse is ready,.

Expected behaviour

The sites with more content than usual work as before (Mozilla Firefox 52 or 2-3 weeks ago)

Notes:

  1. With ABP disabled, all works like before under this default profile.
  2. I created an empty profile, made sure Firefox (last version) works fine, then as soon as I installed ABP (with default filters, so only EasyList), it went downhill, everything was slow. Not as slow or blocking as the default Firefox profile, but a lot slower than before.
  3. I deleted storage.js (was 39MB, now it's 13MB), patterns.ini, patterns-backup5.ini, then restored the filter backup (like suggested in ABP forum). No change.

Change History (10)

comment:1 Changed 6 months ago by mapx

  • Cc trev mapx added

comment:2 follow-up: Changed 6 months ago by trev

The file size is expected given that it now contains both the filters themselves and the backups. Also, processing storage.js isn't terribly efficient - I notified Mozilla about that a while ago but didn't get any response so far. This isn't going to affect your regular browsing however, mostly showing on startup.

What you might be seeing is https://bugzilla.mozilla.org/show_bug.cgi?id=1362779 - does the issue disappear if you go into Firefox preferences and uncheck "Enable multi-process Firefox"? Note that I'm not proposing this as a solution, merely trying to understand the issue.

comment:3 in reply to: ↑ 2 Changed 6 months ago by mariusica77

Replying to trev:
Yes, it all started with netflix homepage not working at all (same as that ticket, version and time period matches), then talked to someone from Mozilla and he suggested removing extensions until multi-process is enabled, also updating graphics driver and nvidia driver. Did all that and stayed with the setting on since. So the issue was present with multi-process disabled too..

comment:4 Changed 6 months ago by harryray2

Latest version causing severe lag on page scrolls etc and constant severe freezes...Issue solved by reverting back to 2.8.2 (or disabling 2.9)

comment:5 Changed 6 months ago by harryray2

this is happening on all sites....

comment:7 Changed 6 months ago by arthur

  • Cc arthur added

comment:8 Changed 6 months ago by arthur

https://perfht.ml/2sc4729
https://perfht.ml/2sbxP7C

This is on Windows 10, Firefox 53.0.3 (32 bits, new profile), ABP 2.9, EasyList+EasyList Germany, EasyPrivacy, Fanboys Social Blocking List and Acceptable Ads (intentionally added some more lists). In both reports I opened the main page of focus.de. Multi-process was enabled.

Last edited 6 months ago by arthur (previous) (diff)

comment:9 follow-up: Changed 6 months ago by trev

  • Resolution set to duplicate
  • Status changed from new to closed

Thank you, I can actually confirm the issue myself on focus.de. We have indeed a write being triggered by filter hit changes, so #5298 will solve the issue for the majority of users. The reason why this is coming up now: browser.storage API that we are using right now seems to be extremely inefficient when saving data. There is https://bugzilla.mozilla.org/show_bug.cgi?id=1320186 but even without sanitization - my performance log shows 2.3 seconds (!) being spent serializing JSON data. Without filter hit counting we will only need to save data rarely and this will be much less of an issue.

Resolving this as a duplicate of #5298.

comment:10 in reply to: ↑ 9 Changed 5 months ago by mariusica77

Replying to trev:
Could you also test on netflix.com ? Open main page, scroll a bit, try to use a different tab. The fix helped a lot with all other sites, but not netflix.com. With ABP disabled completely, it works fine (similar performance with Chrome).

Note: See TracTickets for help on using tickets.