Feed on
Posts
Comments

Introducing Project Snappy

December 1st, 2011 by

Two weeks ago I started project Snappy. The purpose of the meeting is to help us focus on eradicating jarring pauses in Firefox.

Today we had our second meeting (notes).  A surprising amount of work has happened between the first and second meeting:

  • Chromehang was briefly turned on. This converted browser stalls of >30seconds into crashes. This showed that a number of issues are worse than previously assumed
  • We are about to start tracking slow SQL queries via telemetry
  • Even though IndexedDB is the new hotness, existing websites use the evil old DOM Storage API. This API is not asynchronous and degrades browser performance. The workaround is to tell the backend to use async IO.

Just like MemShrink, Snappy bugs fall into three categories:

  • P1: Should be fixed ASAP
  • P2: Should be fixed as soon as developers have cycles for it
  • P3: Everything else

Multiple people have asked whether Snappy is appropriate for bugs caught by Chromehang: ie should we focus on one-off long delays (ie font enumeration) or small delays that happen frequently (ie tab animations). After reflecting on this I decided that UI jank can be thought of as a risk of frustrating the user. Risk has a scientific definition: severity of event multiplied by probability.  Thus a long occasional pause during browsing is equivalent to a frequent short pause.

For next week we plan to wrap up a profiler, come up with a fix for cache io on startup/shutdown, look into submitting hang stacks in a less brutal way.

8 Comments »

8 Responses to “Introducing Project Snappy”

  1. on 01 Dec 2011 at 4:41 pm   Mardeg

    It’d be great to see a site tracking stats called
    arewesnappyyet.com

  2. on 01 Dec 2011 at 5:21 pm   Wes Kocher

    From what I understand, someone from the team has registered arewesnappyyet.com, but hasn’t yet put anything up there.

  3. on 06 Dec 2011 at 8:57 am   Lawrence Mandel

    We need to decide what it is that we want to track on arewesnappyyet.com. Here’s the related bug:

    https://bugzilla.mozilla.org/show_bug.cgi?id=703669

  4. on 07 Dec 2011 at 11:58 am   Ziru

    It would be great if you could create a separate Category for blogs about Project Snappy, similar to the MemShrink category on Nicholas’ blog. That would make it easier for readers who only want to subscribe the latest news about Project Snappy.

  5. on 08 Dec 2011 at 9:59 am   Z

    Just wanted to mention an area where Firefox performs significantly worse than all other browsers (IE8 included).

    If you create a page with lots of JQuery UI sortable lists that are all connected to each other, then firefox becomes very laggy while other browsers show smooth animation during the drag.

  6. on 09 Dec 2011 at 6:04 am   Ed

    I have previously posted this on MemShrink and i dont know if it ever reached your team, So i will post again.

    To cut to the chase.

    I have discover the heavy fragmentation causes a lot of Firefox’s responsiveness problem. I have defrag using Defraggler from Piriform. By File Size and Fragmented Pieces Firefox represent at up to 90% of all fragmentation.

    And for three times in the last three months, whenever Firefox slows down, defrag helps a lot.

    Defrag giving faster performance may seems so simple that is is mostly overlooked.

    I have been on SSD in my Home computer and never experience any of the slow down i have in office HDD. Although there are areas of improvement still with it on SSD, it is at least usable.

  7. on 09 Dec 2011 at 10:17 am   tglek

    Ed,
    If you go back to my older entries. I did a lot of work on fragmentation avoidance…ie our main files do not fragment nearly as much as they used to. We plan to add defrag(which is tricky due to needing admin privs) in the next couple of months.

  8. on 14 Dec 2011 at 1:46 am   Ed

    A Follow up, I am a heavy Tab user with average 40+ Tabs opened at the same time and at peak up to 100s or 200s during the day when i read RSS. So my profile and fragmentation properly happens a lot faster then normal users.

    My previous fragmentation experience was on a Stable Build at office. I have since changed to Beta and Aurora Build to test. One problem i see is once Firefox reaches its maximum possible amount of Physical Memory uses and properly start doing swapping, ( My computer only has 1.7GB Memory ), things will definitely slows down a lot. Compare the same amount of tabs in Chrome, Apart from its stupidly small tabs that is impossible to use, Chrome is still reasonably responsive. While Firefox will be lagging.

    Latest Aurora build do better then Stable, but still way behind.

    Another Point, On my 16GB, SB CPU and SSD, Chrome is still faster then Nightly in responsiveness.