add-ons Firefox Memory consumption MemShrink

McAfee is killing us

A reader named AC commented on last week’s MemShrink report that Firefox was consuming lots of memory on his girlfriend’s computer (emphasis added by me):

I am currently on my girlfriends laptop round at her house and I am surfing the net using Firefox 10.0.1. The memory usage is terrible. It may be because of the two McAfee add-ons that she has, I don’t know, but I can see now first hand how some Firefox users are having an amazing experience and others are still lagging behind. The memory usage as opposed to being 200,000-230,000kb as it would be on my laptop with 11 beta 2 is about 350,000kb or more. That said, there is no loss of performance and that is what matters most. I am not looking for answers or solutions, merely saying that the same or very similar software used on one computer can perform completely differently on another and now I appreciate that even more having witnessed it for myself.

I asked him to try turning off the McAfee add-ons, which he kindly did.  The result (emphasis again added by me):

I did some very very rudimentary tests earlier at my girlfriends house on her laptop and here is what I found.

With the two McAfee add-ons running everything was fine until I got to about 8 tabs and then the memory began to increase. Then it just climbed up to about 450,000 kb. If I was running the same tab load on my latop, I would expect just over half that amount of memory to be reported in task manager.

I have to say that there was no loss of performance, but the amount of memory being used was very high for the tab load.

The first tab that I had open was I right clicked on that tab and hit “Close Other Tabs”. The memory stayed at 418,000 kb and that was it. It stayed at that level for about 10 minutes whilst I went and did other stuff. It wasn’t going up or down. 400MB with just Google UK open and nothing else. It’s diabolical.

So I then disabled the 2 McAfee add-ons and every went back to normal. I used a heavy tab load than before. I opened more tabs with more complex content. I must have had about 15 tabs open and the memory use peaked at 386,000 kb.

Then I logged out of Facebook and Hotmail, without closing any tabs, and within 10 seconds the memory had dropped to 330,000 kb.

Then I closed all but 3 tabs and within 30 seconds the memory was about 180,000.

Then I closed all but one tab and the memory settled at just under 100,000 kb. Back to normal. Exactly how I would expect Firefox 10.0.1 to perform.

The extensions in question were McAfee ScriptScan for Firefox 14.4.1 and McAfee Site Advisor 3.4.1

I didn’t have time to test them individually as things got hectic after that, but as you say Nicholas, the seemingly innocent extensions were ruining the memory performance of a perfectly good browser.

I could still load pages etc and navigate around as fast, but the numbers on task manager were sky high.

Firefox has a reputation in particular for not releasing memory when tabs are closed.  75% of installed add-ons are not hosted on AMO, and thus are out of Mozilla’s control.  This is killing us.  Bug 720856 is my best suggestion for dealing with badly written add-ons such as these ones, but even it feels like weak tea when the problem is so large.

21 replies on “McAfee is killing us”

You don’t need to review all of the 75 percent of addon not hosted by AMO, just review the one that people have most, or pick your battles. Those include Antivirus addons, and then use your judgement like, the skype addon, or those nefarious addons that comes bundled with a lot of popular software.

With the automatic disabling (and opt-in) of third-party addons since version 8, the situation should be better, or no?
However we should do something about these (mostly useless) third-party addons and plugins that behave badly. A lot of applications install these during setup with an opt-in checkbox.
I’ve a question: do the plugins make the performance worse also when they are unused?

Flagging slow amo addons in my opinion is a great move. I kind of doubt if there is a realistic way of doing so, but having some sort of scale (if its even possible, it wouldnt be short term) to show the magnitude of the problem would be even more helpful. IIRC, you also notify users of and disable addons preinstalled in firefox, or installed without a user’s acceptance. And in my opinion, perpetually flagging non AMO addons as orange, and with an !, with a tooltip saying “this addons may or may not be safe, we dont know cuz its not hosted on AMO!” would be incentive for all non AMO addons to get on AMO (since afaik there really isnt a downside).

I can see this sort of thing being kind of a negative for AMO addons (negative reinforcement) but i don’t think that addons not hosted on AMO are at all important to cater to.

magnitude of the problem meaning magnitude of the slowdown per addon. but as i said, i doubt something so specific could realistically be automatically determined.

The blog linked with the “75% of add-ons aren’t hosted on AMO” statistic was for an older version of Firefox. I’d imagine that the third-party add-on confirmation popup in FF8 would have dropped that number. Do we know how successful that popup was (or wasn’t)? Has there been any telemetry data aggregation for post-FF8 add-on installation sources?

IE have the “Add-on Performance Advisor”, that pops up a message on startup saying “Speed up Browsing by Disabling Add-ons [Choose Addons] [Ask me later|v]” (and I think I’ve also seen popups naming individual add-ons). It is quite nagging.

Weren’t there a project statistically trying to correlate start-up speed (or memory usage or crashes?) metric with the addons installed? That is, from end-user data, not from test-machines? This was before telemetry so it might event have been done with insufficient data. Can’t find a reference to it right now, but maybe something like that could be done with the better data from telemetry.

There was. It angered a lot of add-on authors and there were all sorts of questions about the methodology of the measurements. See and the links within it. I think it’s turned off at the moment, but I’m not certain.

Furthermore, start-up time is somewhat amenable to automatic analysis like this, but other aspects of performance such as memory leaks are harder. That’s why I think manual curation is necessary. Also, add-ons not hosted on AMO shouldn’t be exempt from any advisement schemes.

I believe you misread my comment. I specifically said “from end-user data, not from test-machines” and I believe, the case you cited was about data from test machines. The research I meant was older.

I did misread, sorry. I don’t know about that older project. I’m hoping that in the future telemetry data can give us pointers to add-ons that hurt performance.

Hi Nicholas,

Always a pleasure reading your informative posts which are always explained in layman terms for a non-programmer, but firefox enthusiast to understand.

Even though 75% of add-ons are not on AMO, arent there any metric which measure the 50 or 100 most popular add-ons? From these 100, the ones not on AMO should be sent notices to fix their add-ons otherwise they should be blocklisted. If the firefox team started fixing these add-ons, it would be a huge drain on resources and many others might be tempted to not spend the required amount of time fixing their bugs.

Lean and performance seems to be popular, finally, amongst AV makers. Thus they should be more than interested to work with Mozilla to have the best possible performance and memory footprint for their add-ons.

Maybe Mozilla could list those you work closely with on the site as actively working on improving their integration. Even better, give badge to those who jump on the MemShrink effort etc.

Should make the rest follow suite.

Comments are closed.