Skip to content

Comment on This is why memory fragmentation is bad

Comments

Remarkable: "No we don't free chunks right away (except with the new SHRINK GC call). They survive 3 GCs because of allocation heavy workloads. Freeing and allocating right away hurts benchmark performance (bug 541140)."

So they're basically saying one of the reasons a copy of Firefox with no open tabs is currently consuming 1GB of my computer's memory is because they didn't want to suck on benchmarks. Is there a flag I can set to tell the damn browser "I AM A REAL USER AND NOT A BENCHMARK, PLEASE DON'T SIT ON 1GB OF MEMORY, FREE IT IMMEDIATELY"?

In FF6 (available right now on the Aurora channel and in the next few days on the Beta channel) and later versions you can go to about:memory and click on the "minimize memory usage" button at the bottom. Maybe do it a couple of times for luck.

We're working on improving things. See https://bugzilla.mozilla.org/show_bug.cgi?id=656120 for another big improvement that will go into FF7.

Neat: will actually give me a reason to upgrade from 3.6.

That's a terribly depressing thread towards the end.

Yeah, risk management is really depressing when you get to it. Still needs to be done, though.

I'm not so sure. The price of getting releases out every 6 weeks is that we must be conservative with what we backport.

I have 6G of core and 4G of swap. If using more memory makes browsing faster, I'm all for it. Memory is cheap. CPU time is expensive.

For reference: 24G of DDR3 costs about $220 these days.

All of the physical RAM in the world doesn't mean a damned thing if you're a Win32 process limited to 2 GiB of user address space. Heap fragmentation is a very real problem there.

So don't run win32. :) We've had 64-bit processors for a while now, run a 64-bit OS and you have all the address space you might want.

LOL. Yesterday, I restarted firefox because it ate 13GB of virtual memory and started to get really unusable.

And even on 64-bit Windows, 32-bit Firefox will get the full 4 GB of address space.

On machines where I have at least 4G of ram, I configure them to not use any swap space at all.

If a process needs (or pretends to need) that much memory, the swapping will just kill the performance, and the machine gets unresponsive. I rather have the OOM killer do its job, have a few processes dying and be able to continue using the machine.

I do the same on a Netbook with 2G of RAM. It gets a little hairy sometimes so I always need to keep an eye on Process Explorer, but the performance boost is huge.

As far as I'm aware, there's no other method to disable the default Windows behaviour of swapping out programs even when sufficient RAM is available.

Doesnt matter how much youve got if usage continues to grow unchecked.

...and programmer time costs much more. So yes, normally that's a great attitude.

But still, the app has to run on real machines today. So its worth a "sweeping up" pass before release, to fix gross oversight and bugs that leak/use CPU egregiously.

My guess is that it isn't just because of benchmarks running a gc takes time, running it all at once can be faster then running it multiple times. Getting the right balance can be hard.

I think you're jumping the gun. He may be talking about benchmarks that represent the user experience. In which case he's guilty at most for using 'benchmark performance' instead of 'user experience'.

Well that's definitely not only for benchmarks. Whenever you have animations that use JS you will benefit from this approach.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.