3 ms·

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 b

by ori_b 17y ago

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.

Tichy 17y ago
Could be some plugins rather than FF itself?
- ori_b 17y ago
  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.
  - Tichy 17y ago
    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".
JulianMorrison 17y ago
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.
- ori_b 17y ago
  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.
  - JulianMorrison 17y ago
    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.
    - ori_b 17y ago
      Ah, right. I wasn't thinking of C++ destructors, since I usually program in C these days. In that case, you're probably right.

by ori_b 17y ago

Tichy 17y ago

Could be some plugins rather than FF itself?

ori_b 17y ago
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.
- Tichy 17y ago
  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".

JulianMorrison 17y ago

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.

ori_b 17y ago
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.
- JulianMorrison 17y ago
  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.
  - ori_b 17y ago
    Ah, right. I wasn't thinking of C++ destructors, since I usually program in C these days. In that case, you're probably right.