Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Chrome and Firefox 3.5 Memory Usage

dotnetperls.com

Post reply on HN
Print view View original

41–46 of 46 posts

Re: Chrome and Firefox 3.5 Memory Usage

#41

Post by ori_b »

JulianMorrison wrote: post #39
ori_b wrote: post #22

Earlier quoted context omitted.

I agree. Closing firefox through file->quit takes at least 30 seconds for me, during which I can hear the laptop's fan spinning up. Usually I just kill -9 it because I don't have the patience to wait. Firefox 3.0.11, on a dual-core low-voltage laptop with 1 gig of ram. It's fast enough to run everything I care about but firefox.

C/C++ programs that manually memory free at exit are doing it wrong. They ought to (1) write everything to disk they need to save (2) fsync (3) send themselves a SIGKILL. The OS will tidy up the memory.

SIGKILL? Uh, you know there is a little function called exit() that exits the program.

Other than that, yes, I agree with you, but I suspect what's actually taking all the time is paging back in the data that it wants to write to disk when it syncs, and not necessarily freeing the memory.

Re: Chrome and Firefox 3.5 Memory Usage

#42

Post by JulianMorrison »

ori_b wrote: post #41
JulianMorrison wrote: post #39

Earlier quoted context omitted.

C/C++ programs that manually memory free at exit are doing it wrong. They ought to (1) write everything to disk they need to save (2) fsync (3) send themselves a SIGKILL. The OS will tidy up the memory.

SIGKILL? Uh, you know there is a little function called exit() that exits the program. Other than that, yes, I agree with you, but I suspect what's actually taking all the time is paging back in the data that it wants to write to disk when it syncs, and not necessarily freeing the memory.

SIGKILL because it gives finalizers and at-exit handlers no chance to run. The building has been emptied: knock it down, don't waste time picking it apart brick by brick.

I doubt that paging all the stuff it wants to write is the reason. If that were the case, killing it during the grind would corrupt its save files, and the time duration of the grind would be proportional to what needs saving (just a few files of fairly constant size) versus proportional to how much memory it's hogging.

I think it's paging all right - it's paging back in every fiddling little object to call its finalizer.

Re: Chrome and Firefox 3.5 Memory Usage

#43

Post by Tichy »

ori_b wrote: post #40
Tichy wrote: post #37

Earlier quoted context omitted.

Could be some plugins rather than FF itself?

It's possible, I suppose, but I seem to remember that it happened long before I added any extensions (I don't have very many - 2 or 3 of the more popular ones like adblock and firebug). I guess it wouldn't hurt to experiment again.

I had it very infrequently, and I have only 3 plugins installed. Haven't experienced it since I have a "click for flash" plugin. I still suspect that it was one of the may sites I kept open that brought down FF. The browser should prevent that, but if a site can bring down FF, it would be more like a bug than a general shortcoming of FF.

It's definitely not reproducable like "open 20 tabs and FF will slow to a crawl".

Re: Chrome and Firefox 3.5 Memory Usage

#44

Post by ori_b »

JulianMorrison wrote: post #42
ori_b wrote: post #41

Earlier quoted context omitted.

SIGKILL? Uh, you know there is a little function called exit() that exits the program. Other than that, yes, I agree with you, but I suspect what's actually taking all the time is paging back in the data that it wants to write to disk when it syncs, and not necessarily freeing the memory.

SIGKILL because it gives finalizers and at-exit handlers no chance to run. The building has been emptied: knock it down, don't waste time picking it apart brick by brick. I doubt that paging all the stuff it wants to write is the reason. If that were the case, killing it during the grind would corrupt its save files, and the time duration of the grind would be proportional to what needs saving (just a few files of fa…

Ah, right. I wasn't thinking of C++ destructors, since I usually program in C these days. In that case, you're probably right.
Post reply on HN