All About Performance

and other stuff by Taras Glek

Introducing Project Snappy

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.

Comments