Snappy, April 19

At 15 minutes, this might’ve been our shortest meeting yet (notes).

Most of the work happened in frontend stuff. Most notable improvements are reduced screenshot overhead (by taking less screenshots, bug 744152) and a brand new IE migrator (a step towards fully async places API, bug 710895).

Work resumed on making peptest return more consistent results.

The necko team decided to take a more involved approach to solve our cache locking(bug 722034) which means the fix will land later than we originally hoped for.

My little investigation into setTimeout overhead exposed more overhead than I expected. After our regularly scheduled snappy meeting, we had a follow up meeting to spec out how to change our event handling to cope with this (bug 715376). Our best people are on this 🙂 I asked for someone to prototype an extension to suspend background tab activity, sounds like  Wladimir of adblockplus might lend a hand.


  1. I was wondering a few things about project snappy.

    1. Will any of the work be discarded when the multi processor scaling will begin to happen.

    2. The super snappy work, were the guy is trying to get all the content to run off separate thread, will this be discarded or used for electrolysis.

    3. If fenec uses electrolysis and is successful why can’t it be ported to the desktop version.

    I ask this because mozilla put such a tremendous amount of effort into electrolysis. Its kind of strange seeing the one project that will make things noticeably faster put on hold, I mean thats why fenec is using electrolysis isn’t it.

  2. 1. No. Snappy is stuff we’d have to fix irrespective of any future multiprocess/etc changes
    2. Too early to tell where that will lead
    3. Fennec multiprocess gave us a huge perf hit. We ended up going with multithreading on android. B2G use a more traditional e10s arch because we control the OS and overheads it imposes. So yes, e10s arch is portable and works on desktop. Problem is rewriting our browser chrome AND breaking a lot of extensions. If things work out perfectly, we could progress via snappy -> supersnappy -> e10s resulting in incrementally improved experience and minimal regressions for the user, but it’s too early to tell.

  3. Now it seems more clear. I was just confused about about the direction and the significance of these projects. Thanks for the reply it makes more scene. Kind of sad how snappy isn’t getting all the attention it deserves.

  4. linux_op:
    I think many firefox users do care the progress of snappy and memshrink. The problem is there seems to be many projects for mozilla this year. B2G, and especially whatever under the name “Kilimanjaro” have already consume most resources, IIUC. Hopefully they can balance it, and return to focus on snappy/memshrink ASA the 1st “Kilimanjaro” release. Because snappy/memshrink are also the key to “Kilimanjaro”, so I have hope of it. By the time ff18 release(Jan 1st, 2013), if the total number of snappy P1 bug can be driven down to 30, there should be a good enough milestone.

  5. Great now Kilimanjaro will make firefox have EVEN MORE overhead which will make it lag, crash,and loose more users because of it. The product is not polished, nor is it even near the quality to the competing browsers, interms of performance, and in many cases standards compliance, and yet mozilla decides to add more features. Wait on top of that they also halt the development of snappy which is trying to polish the product and make it somewhat near competitive to other browsers. Just gotta say, nice manager you guys got there. But it is interesting what that project will bring.

  6. K9O is in no way halting snappy. There is some resource contention in terms of developers, but there are always multiple priorities to juggle.

  7. Well Im just happy that there is at least some progress in snappy, and really, its not bad at all. Im just saying its this whole performance issue is a big reason why people have left firefox for chrome. That fact should of been made more obvious to the product managers, but at least they are addressing this issue. There are good results because of it.

  8. FYI, the fact that perf matters is not lost on product managers. This is why I was volunteered to run snappy.


    That bug seems to be dead in the water. Is the code super complex that they need time to analyze or are they stuck on other projects?

  10. I’m told it’s super complex. They also had to scrap the approach they took to fixing it initially.