4 ms·

I've got a billion tabs open in Firefox, (plus a bunch of extensions) which seems to expose some O(n^2) algorithm in the internals, because it becomes unusably

I've got a billion tabs open in Firefox, (plus a bunch of extensions) which seems to expose some O(n^2) algorithm in the internals, because it becomes unusably slow after running for 24 hours. I can either quit it normally, which takes 7 minutes-- or just kill the process and restart it.

sitkack 12y ago
Undo is expensive and error prone.
- TheLoneWolfling 12y ago
  ...unless you're using (structure-sharing) persistent data structures throughout, in which case it is practically trivial. Mind you, this has other issues. (Although, if you want to preserve undo/redo over (unintended) shutdowns, it becomes much more difficult.)
  - sitkack 12y ago
    Which I would argue that a persistent data structure allows you to go back in time to a snapshot. It doesn't actually attempt to mutate back to a previous state. But yes and yes.
mtdewcmu 12y ago
Firefox is a house of cards, because all those billion tabs are sharing a single process and they all need to cooperate perfectly.
- Dewie 12y ago
  In what ways do the tabs need to cooperate/interact?
  - pessimizer 12y ago
    They have to share the same thread. If one blocks, they all block.
    - mtdewcmu 12y ago
      There are many threads, but threads are not isolated by the OS to the same extent as processes; hence, their fates are all intertwined. The user can't kill one misbehaving thread, and even if you could, you couldn't expect the program to be stable afterward.
      - coryrc 12y ago
        Heh, I have attached to the process, went to the stuck thread, went up a few frames, and told it to return. Never did recover, as expected :) But before it restored all your tabs it was worth a shot at saving the state.
  - mtdewcmu 12y ago
    You'd have to know the source code quite intimately to answer that. My hunch is that when it slows down, what you'd see under the covers is a tangled mess of locks and some kind of leaking resource(s). If the tabs were more isolated, you'd be able to at least kill the ones most responsible and the others would survive. Chrome consciously chose to isolate tabs in separate processes; having more explicit separation probably discourages tangled dependency chains and that might be the best explanation for why, even though you could, you don't have to resort to actually killing processes that often.
killertypo 12y ago
and when you kill the process and restart it, it will gladly restore your session and the memory will be in a better state. It will still degrade, but for a short time it's going to be awesome with all of those tabs until the leaky memory finds its way back into your browser.

sitkack 12y ago

Undo is expensive and error prone.

TheLoneWolfling 12y ago
...unless you're using (structure-sharing) persistent data structures throughout, in which case it is practically trivial. Mind you, this has other issues. (Although, if you want to preserve undo/redo over (unintended) shutdowns, it becomes much more difficult.)
- sitkack 12y ago
  Which I would argue that a persistent data structure allows you to go back in time to a snapshot. It doesn't actually attempt to mutate back to a previous state. But yes and yes.

mtdewcmu 12y ago

Firefox is a house of cards, because all those billion tabs are sharing a single process and they all need to cooperate perfectly.

Dewie 12y ago
In what ways do the tabs need to cooperate/interact?
- pessimizer 12y ago
  They have to share the same thread. If one blocks, they all block.
  - mtdewcmu 12y ago
    There are many threads, but threads are not isolated by the OS to the same extent as processes; hence, their fates are all intertwined. The user can't kill one misbehaving thread, and even if you could, you couldn't expect the program to be stable afterward.
    - coryrc 12y ago
      Heh, I have attached to the process, went to the stuck thread, went up a few frames, and told it to return. Never did recover, as expected :) But before it restored all your tabs it was worth a shot at saving the state.
- mtdewcmu 12y ago
  You'd have to know the source code quite intimately to answer that. My hunch is that when it slows down, what you'd see under the covers is a tangled mess of locks and some kind of leaking resource(s). If the tabs were more isolated, you'd be able to at least kill the ones most responsible and the others would survive. Chrome consciously chose to isolate tabs in separate processes; having more explicit separation probably discourages tangled dependency chains and that might be the best explanation for why, even though you could, you don't have to resort to actually killing processes that often.

killertypo 12y ago

and when you kill the process and restart it, it will gladly restore your session and the memory will be in a better state. It will still degrade, but for a short time it's going to be awesome with all of those tabs until the leaky memory finds its way back into your browser.