VIM Color Scheme Test is hogging memory & loading slowly with uBlock

[Mikey1993]

As requested from the developers:
Issue 443432: VIM Color Scheme Test is loading slow and hogging memory

gorhill edit: "Chrome version: 41.0.2251.0 Channel: canary".

[harshanvn]

Here are my numbers, for below browsers, if it adds any value -

Chrome 39 64 bit: (enabled) 1124 MB, Loaded in 24 seconds (Avg run 2 times).
(disabled) 763 MB after VIM site loaded, Loaded in 14 seconds.

Firefox 34 32 bit: (enabled) 448 MB, Loaded in 12.46 seconds.
(disabled) 365 MB, Loaded in 8.75 seconds.

Firefox Nightly 32 bit (inside sandboxie): (enabled) 455 MB, Loaded in 15.4 seconds.
(disabled) 404 MB, Loaded in 10.3 seconds.

All the memory results were captured in windows task manager and used stop watch to measure timings, so it could off by a percent or two.
For firefox Noscript addon was present. For Chrome uMatrix was present.

[gorhill]

Chrome 39 64 bit: (enabled) 1124 MB, Loaded in 24 seconds (Avg run 2 times).

I believe you used F5 to refresh the VIM page. It's important that everybody uses the same measurement steps, or else numbers will be all over the place. For whatever reason, when a tab is merely refreshed in Chromium, a lot of memory is not released, as opposed to if you close the tab and paste the URL in a new tab.

Also, I always leave enough time for the garbage collector to kick in (Chromium, may have to wait long with later version), or force GC with Firefox's about:memory. This results in better quality figures -- though the peak memory figures have values too, it's just that they are more ephemeral and more difficult to compare.

[harshanvn]

nope i have closed the browser and re ran. Also, in all the browsers, used Private Browsing..
Also, i have not done any force GC or anything like that. Just after completion. Waited for 5 seconds or so and took the measurements from task manager.

[gorhill]

Ok, then you have one or more extra extensions active. The test must be done with only uBlock. Other extensions may also inject content scripts, which will further boost memory footprint. I just never went as high as above one GB in all my tests. For example if I enable PDF viewer, I get 1.1 GB.

[harshanvn]

ok i will disable other extensions. And repeat everything.

[Mikey1993]

Try adding this command line switch to Chrome executable:
--disable-extensions
instead of disabling only uBlock, and compare the results.

[gorhill]

--disable-extensions

Not sure it's a good thing if you want to compare "with uBlock" vs. "without uBlock". There are extensions which are not necessarily visible/listed, those that are built-in. If these are disabled, and if they contribute memory footprint to a web page, then you end up with a steeper memory footprint difference than strictly "with uBlock" vs. "without uBlock".

[Mikey1993]

Well, so there would need to be 3 benchmark runs to see if the command line switch does anything memory wise by disabling ALL the visible & invisible extensions.
If the memory is still high with only disabling uBlock, then it means that there is another added extension/module that causes the bug.

[gorhill]

I tried the same test on Chromium 39 64-bit Linux with Adblock Plus 1.8.8 with same filter lists as uBlock, and the VIM page peaked at above 4 GB, and settles to above 3.6 GB (after ~2-3 minutes).

I wonder what the results would be on Chrome 41 (I don't have it installed).

[Mikey1993]

Adblock Plus 1.8.8 also inhibits the same issue on Chrome Canary (41).
I've got an OOM crash while loading the test page.

[harshanvn]

Here are the results for the tests rerun as advised..

Chrome 39 64 bit: (enabled uBlock only) 800/800 MB, Loaded in 16.7/15.6 seconds.
                  (disabled all) 106 MB/107 MB, Loaded in 5.39/6.28 seconds.

Firefox 34 32 bit: (enabled uBlock only) 375.4/376 MB, Loaded in 9.7/8.8 seconds.
                   (disabled all) 285/281 MB, Loaded in 6.9/6.68 seconds.

Nightly 32 bit (sandboxie): (enabled uBlock only) 365/365 MB, Loaded in 8.05/8.74 sec. 
                       (disabled all) 264/255 MB, Loaded in 5.6/4.86 seconds.

Memory Results: For Chrome used its own task manager to report VIM tab, For Firefox used 
Windows Task Manager
Time: Used Stop Watch

[gorhill]

@harshanvn Yeah, close enough, though I can see the GC did not kick in in the first test -- Chrome needs to be left idle for 2-3 minutes to be sure. Note that the bug reported in first comment is for Chrome 41.

There is really not much I can do anymore to improve uBlock for this stress test at this point. The Chromium devs will have to do something to lower the CPU/memory overhead of injecting scripts.

I did my home work: I actually constantly used the VIM benchmark (among others) throughout development since the very beginning as a tool to push optimization. I quickly went through the content scripts and really it's all tights in there, not much place for improvements.

Chromium's memory footprint has been inching up in latest releases (as I already noted in the past), and apparently as reported by @Mikey1993, Chromium 41 is even worst -- this is the issue.

[harshanvn]

@gorhill , my thoughts were almost exactly the same. I think the ball is in their court. Some thing should be going wrongly in the dev version of chrome.

On the side note, firefox nightly, seems to be doing good even under the sandboxie. I think it will add some overhead.

[Mikey1993]

@gorhill Yep, that's also why I've opened this issue on the Chromium issue tracker first.

[mzso]

@gorhill commented on 2014. dec. 20. 14:15 CET:

Ok, then you have one or more extra extensions active. The test must be done with only uBlock. Other extensions may also inject content scripts, which will further boost memory footprint. I just never went as high as above one GB in all my tests. For example if I enable PDF viewer, I get 1.1 GB.

Hi!
Any way to determine which other extensions are at fault? Or what sort of extensions should I look for?
After moving to ublock I tested with this page but it was just as bad. Since it looks like it's not ublock I gotta figure out what else is causing it...