Snappy, April 26

Notes from today’s meeting are here.

No major snappy fixes landed this week. However, if you look in the notes, there are quite a few projects going through the review cycle.

Personally, I’m most excited by progress in getting rid of the setTimeout on tab click(bug 743877). Neil posted a diagnosis of why we need setTimeout while switching tabs. Tim followed up with a patch to avoid the setTimeout for non-focus bits.
On the subject of SetTimeouts: we devised a plan for managing SetTimeout overhead in background tabs. This will involve breaking up our global event queue into a global queue + smaller per-page queues, bug 715376. This will not be a pleasant task, but Nathan aims to have a proof of concept ready next week. With this infrastructure we should be able start prioritizing which events we handle and punish misbehaving tabs.

The graphics team is wrapping up the big Android push, freeing up cycles for elsewhere. Bas is back to looking at slowdowns due to hw acceleration (bug 721273). Bas is also looking into changing our chrome CSS to be less expensive to paint.

Ehsan is working with Paul to change firefox themes to not be horrible performance hogs.

Update: A very significant snappy fix landed this week as part of memshrink. It should significantly reduce memory usage and thus cycle-collector pauses, etc.

Update #2: I missed another very cool Snappy fix: bug 729133. This is based on revising old assumptions about cache being faster than disk. We learned from telemetry data that a significant portion of disk cache requests are processed slower than they would if we just went straight to network. Firefox now hedges bets and warms up a TCP connection while checking cache. For details see Patricks’s blog.


  1. Bug 695480 is a major Snappy bug which landed recently.
    It is marked as MemShrink, but it is even more about
    responsiveness, since it should prevent
    zombie documents in certain cases. Zombie documents
    make CC times high.

  2. No news on supersnapppy ><…… someday someone may just start a kickstater project on that…

  3. @Ed, Brian works quietly, but effectively. I expect good things.

  4. taras, do you miss this one?
    It’s marked as Snappy:P1, may help user experience faster page load, sometimes?

  5. Multiple users-

    I am often confronted with the following problem-

    I have carefully set up user switching on my macs-
    so my kids can play web games, mess about on youtube, without impacting my own work environment.

    There are thus often two or three instances of
    firefox active. However, even when a person
    is not using a session firefox can
    actively eat lots of CPU, and set of the fans,
    generally slowing the whole system down.

    Is there a way of setting up a much stronger throttling of firefox if it is not in the active
    session… There was already some talk about this a couple of weeks back for tabs, but this seems even more
    useful. Even music playing, (for instance), in one of
    these sessions is not sent to a speaker

  6. @tglek: Thx, i hope the community could just hold on a little longer before Firefox regain some market shares.

  7. @augustm, I’m not sure how we would do this. This might be easier to do via OS functionality like kill -SIGSTP to suspend inactive instances. Android solves this by killing background apps forcing apps to restart and restore state when you return to them.

  8. Hello,

    the SIGSTP could be an answer, if it could
    be sent to firefox and the plugin compartments
    on a user switch…

    The kill is too strong since it looses the context
    of the pages which are active.

    It would resolve a major problem that I have at
    home but also in my university lab where we also
    have user switching activated — with machines getting bogged down by background sessions

  9. why was my comment deleted?