Closed fireattack closed 3 years ago
uBlock-user
commented
3 years ago Speculated performance issues will be marked as invalid and closed if they do not come with actual profiling data from Firefox Profiler/Chromium Profiler + fully substantiated analysis supporting the claim.
fireattack
commented
3 years ago Sorry, the profiler is attached. Is there anyway to re-open it?
Thanks. Profile-20210818T110514.json.txt
A Gif to show it too:
Without uBo:
With uBo:
fireattack
commented
3 years ago After some further testing, it look like disabling Easylist can eliminate the issue (despite no rule is actually triggered. I guess it's simply its huge amount of rules.)
uBlock-user
commented
3 years ago I guess it's simply its huge amount of rules.)
Number of rules never been a problem for uBO, the second gif displays the lag which is only experienced when you have another software running or another extension hogging the CPU concurrently. I don't see this issue either Firefox or Chromium.
fireattack
commented
3 years ago Well, I followed the guide and use a new profile with only ubo extension. Simply "disable on this site" would be enough to eliminate the issue, I don't even need to disable uBo (even though I did in control group).
I can see it probably won't be easy to reproduce on a beefy computer, but the issue is indeed caused by uBo+Eayslist combination here on my computer by controlling the variables.
gorhill
commented
3 years ago I can't reproduce such issue with uBO + default settings and (up to date) lists.
The profiling data show all the time is spent in "Recalculate style", which is browser code -- I see nothing for uBO.
See if disabling cosmetic filtering make the issue disappears. If so, then I suspect there might be a highly generic cosmetic filter in EasyList which is causing an issue on this page, but only on your side, maybe as a result of graphic driver issues, something you will have to investigate. If a highly generic cosmetic filter is causing you issue, you should have the same problem with AdGuard or ABP, which you may try without uBO to validate whether this is the issue.
fireattack
commented
3 years ago fireattack
commented
3 years ago I tried to bisect it, but it looks like that it's not any specific rule, but the existence of any of these generic cosmetic rules will gradually affect the performance.
Particularly, if I manually copy and put rules started with ##a[ and ##div[ (around 760 lines) into my filter (and disable EasyList), it is enough to make it almost as bad as the entire EasyList.
fireattack
commented
3 years ago Never mind, using the other half of all these ## rules is just as bad.
So I guess nothing we can do then.
Feel free to close this issue if you guys feel like nothing needs to be added. Or let me know if you want anything from me.
Cheers!
gorhill
commented
3 years ago You can just disable cosmetic filtering, that will help, but I feel it's not normal that you browser can't cope with the generic cosmetic filters, the issue would be more widely reported if it was affecting everybody, I feel there is something specific on your system at the root of it -- there was 8 seconds of "Recalculate style" out of 14 seconds in your profile, this is just not normal (I don't have a "beefy" computer, so I would be able to reproduce something if this was the reason).
fireattack
commented
3 years ago Yeah that's a possibility.
It's worth noting that I never encountered such issue on other sites, and even on the same https://bugs.chromium.org/p/chromium/issues site, I don't have this issue on other tickets either (which I assume is because this webpage is significantly longer and therefore more heavy).
fireattack
commented
3 years ago Oh, and I don't have such problem on Firefox (just did a quick test with my main profile, so with all kinds of other extensions).
gorhill
commented
3 years ago Here are the cosmetic filters injected unconditionally by uBO, there are 1023 of them (deemed "highly generic" by uBO), so this might be easier to bisect than trying out all of EasyList's generic cosmetic filters -- if you are still curious as to which one(s) is causing this issue:
uBlock-user
commented
3 years ago additional observations: disabling all filter lists fixes the issue as well while disabling only EasyList or uBlock list does not fix the issue however
Instead of disabling any lists at all, you can add @@||bugs.chromium.org^$ghide
uBlock-user
commented
3 years ago As per the discussion, this sounds more like a browser issue as gorhill points out in - https://github.com/uBlockOrigin/uBlock-issues/issues/1687#issuecomment-901270580, so I doubt anything can be fixed here.
uBlock-user
commented
3 years ago Does uBO logger skip reporting some generic cosmetic filters?
uBO won't report cosmetic filters in the logger if the elements that would have been blocked were removed from the DOM by the site code itself(done by anti-adblock scripts sometimes, I don't believe that's the case here.)
fireattack
commented
3 years ago I don't think any filter is actually triggered (hence no log, if I understand what you mean correctly), just the process of checking them causes this performance issue on Chrome.
In my previous bisect attempt using the ~1000 "Highly generic cosmetic filters" (similar to what gorhill lists but not exactly the same), I can reproduce the issue with either half of it. And further reducing the number of rules applied will make it gradually better and better.
uBlock-user
commented
3 years ago @fireattack does this issue only occur at bugs.chromium.org ?
gorhill
commented
3 years ago However, could you explain, given tha fact there are no generic cosmetic filters being reported in the uBO logger when visiting the site, why disabling generic cosmetic filters fixes the issue?
Yes, I can explain.
The list of filters I posted above are deemed "highly heneric" (1,023 with default lists), and uBO injects unconditionally such filters. The logger does not report those filters because none are matching anything in the DOM.
For the "lowly generic" (currently standing at 22,167 with default lists), uBO injects only those for which there is a match in the DOM -- which means zero on that page. Keep in mind that AdGuard and ABP injects all highly and lowly filters unconditionally, not just the highly generic ones
The logger reports only those cosmetic filters which were found to have an effect on a page, i.e. for which there was a match.
I see this page makes use of a lot of shadow-root elements in the DOM, so maybe this could be related.
gorhill
commented
3 years ago I consider it's a browser issue given that:
Given this, I am pretty sure Chromium devs would want to understand the cause of this as this makes Chromium look bad compare to Firefox.
fireattack
commented
3 years ago @fireattack does this issue only occur at
bugs.chromium.org?
So far yeah, I only see this on bugs.chromium.org.
fireattack
commented
2 years ago A quick update: I have noticed similar issues more and more on other sites, especially heavy sites like Amazon and Twitter. It often causes all the interactions to be "laggy", including typing, context menu, and scrolling.
I don't know if it's a different issue or still the same (since it can also be eliminated by disabling cosmetic filtering), so I don't want to open a new issue. A performance profile I recorded on Amazon.co.jp (visiting this url) below in case anyone wants to have a look.
Profile-20220131T022822.json.txt
Thanks!
gorhill
commented
2 years ago It's the same as was found above, that page is spending a huge amount of time in recalculating styles, including as the mouse move. uBO's own code is not the issue here. Since there are no other report of such issue, please share the troubleshooting information at the bottom of Support pane, it seems something very specific to you is occurring on your side.
fireattack
commented
2 years ago Thanks for confirming, I would see if I can report it to chromium or Amazon.
gorhill
commented
2 years ago Some sites do not like to have certain of their resources blocked, so if you misconfigured uBO with bad filters/rules/lists, this could be the cause -- hence why I asked to share troubleshooting information. Beyond this, did you enable experimental features in chrome://flags? Did you disable "Use hardware acceleration when available" in Chromium's settings?
fireattack
commented
2 years ago uBlock Origin: 1.40.9b4
Chromium: 97
filterset (summary):
network: 65000
cosmetic: 72296
scriptlet: 19230
html: 0
listset (total-discarded, last updated):
removed:
easyprivacy: null
plowe-0: null
ublock-badware: null
ublock-privacy: null
added:
CHN-0: 27774-88, 3h.20m
fanboy-cookiemonster: 21956-14, 3h.20m
ublock-annoyances: 4375-117, 3h.20m
default:
user-filters: 211-6, never
easylist: 62497-19, 3h.17m
ublock-abuse: 77-0, 3h.15m
ublock-filters: 30158-172, 3h.13m
ublock-unbreak: 1692-14, 3h.12m
urlhaus-1: 8270-0, 3h.11m
filterset (user): [array of 211 redacted]
trustedset:
added: [array of 91 redacted]
removed:
chrome-scheme
edge-scheme
moz-extension-scheme
vivaldi-scheme
wyciwyg-scheme
switchRuleset:
added: [array of 7 redacted]
hostRuleset:
added: [array of 8 redacted]
modifiedUserSettings:
advancedUserEnabled: true
cloudStorageEnabled: true
hyperlinkAuditingDisabled: false
prefetchingDisabled: false
modifiedHiddenSettings:
cloudStorageCompression: false
supportStats:
allReadyAfter: 669 ms (selfie)
maxAssetCacheWait: 279 ms
Above is with my main UBo settings. I tried to reset to default and the problem persists. It does become somewhat better if I disabled all the other extensions, but that's kinda expected.
As for flags, I don't think I disabled any relevant ones; but it's a relatively outdated computer.
gorhill
commented
2 years ago I think it would be worth for you to create a new browser profile and test again with only default settings in both Chromium and uBO with up to date list -- do not add/remove any lists, do not add any filters/rules -- see if the issue is still there.
fireattack
commented
2 years ago Can reproduce in a new profile with Chrome Canary, with nothing but uBO dev build in all default.
The responsiveness is better than my heavy main profile, but still noticeably laggy.
gorhill
commented
2 years ago Seems worst than the previous profile -- I see a huge amount of time spent in Amazon's own code which seems to be jQueryUI, more specifically most time is spent in a fix() function:
fix: function(a) {
if (a[c.expando]) return a;
var b = a;
a = c.Event(b);
for (var d = this.props.length, e; d;) e = this.props[--d], a[e] = b[e];
a.target || (a.target = a.srcElement || q);
3 === a.target.nodeType && (a.target = a.target.parentNode);
!a.relatedTarget && a.fromElement && (a.relatedTarget = a.fromElement === a.target ? a.toElement : a.fromElement);
null == a.pageX && null != a.clientX && (d = a.target.ownerDocument || q, b = d.documentElement, d = d.body, a.pageX = a.clientX + (b && b.scrollLeft || d && d.scrollLeft || 0) - (b && b.clientLeft || d && d.clientLeft || 0), a.pageY =
a.clientY + (b && b.scrollTop || d && d.scrollTop || 0) - (b && b.clientTop || d && d.clientTop || 0));
null != a.which || null == a.charCode && null == a.keyCode || (a.which = null != a.charCode ? a.charCode : a.keyCode);
!a.metaKey && a.ctrlKey && (a.metaKey = a.ctrlKey);
a.which || a.button === p || (a.which = a.button & 1 ? 1 : a.button & 2 ? 3 : a.button & 4 ? 2 : 0);
return a
Prerequisites
I tried to reproduce the issue when...
Description
When uBo is enabled, typing in text area becomes very laggy.
A specific URL where the issue occurs
https://bugs.chromium.org/p/chromium/issues/detail?id=534732
Steps to Reproduce
Expected behavior
They letters get on the screen immediately as you type.
Actual behavior
The whole typing experience is very laggy. You wee see sometimes the letters only start to appear after you typed like 15+ letters.
uBlock Origin version
1.37.2
Browser name and version
Google Chrome 92.0.4515.159 (Official Build) (64-bit) (cohort: 92_win_159)
Operating System and version
Win7 x64