Closed gorhill closed 9 years ago
My answer:
I've been playing a video for 40 minutes now, and the memory footprint of the extension stands at 51MB (Chromium 64-bit with all filter lists selected except regional ones), which is typical given I have forced a reload of the filters by changing my custom filters on top of all this. What other extensions do you have installed? The browser's garbage collector make take longer to kick in when the browser is not idle enough. So if some other extensions are causing higher CPU usage, the browser won't fall into idle mode, and the garbage collector will become lazier. Currently my CPU stands at 5% for the Youtube tab, which seems sufficient for the garbage collector to kick in. Do you have the request log enabled?
Correction: My Youtube tab's CPU usage was more like slightly above 10%. Correction to correction: No, the CPU was really 5%: if the Youtube tab is not the active one, which was the case when I read the figure.
Testing the playback of a Youtube video without and with uBlock:
Just can't reproduce. The lower memory footprint of the Youtube tab with uBlock above is not because uBlock causes Youtube tabs to consume less memory, it's just illustrative that the browser's garbage collector is not very predictable.
From now on, any performance claim held as a fact such as "caused by uBlock" will have to come with minimal amount of data so that I don't investigate pointlessly the little time I have left. References to be used for comparison are without uBlock, and/or with ABP.
I just saw an instance where the Youtube web page reached above 300MB, and forcing garbage collection didn't bring the memory under 300MB. Need to investigate why.
Net request logging is turned off.
I took heap snapshots and looked at the diff. I cannot see anything which I can trace back to uBlock. From a superficial examination, it does appear a lot of memory is being allocated by html5Player.js
. I am wondering if it could be a case of html5Player.js
code not dealing properly with net requests which are blocked (i.e. not cleaning up properly used memory in the event of an error). Need to investigate more deeply.
I wonder if #193 could be behind this.