Snappy, May 3rd: Faint hope of handling mousedown events without a setTimeout

Meeting notes.

Memshink had a good idea to switch to bi-weekly meetings. We are going to try the same for Snappy. My plan is to still solicit status updates and blog weekly, but only meet in person every two weeks. The next meeting will be on May 17.

Borders/Gradients

Turns out that most of the painting overhead in accelerated versions of Firefox is spent rendering borders and gradients. I blogged a little about this earlier. It’s a combination us not caching gradients and being overly picky about rendering border corners perfectly (ie to spec). Our chrome renders particularly slowly because as our chrome CSS changed (after implementing d2d accel and optimizing for exists codepaths), we started hitting more slow paths in the border code. We need telemetry to notice when things are rendering slower than expected.

According to Bas we need to enable Azure for content and then start implementing respective caches. We should get significant speedups within 3-4 weeks, but to get close to the baseline performance of the no-borders/gradients build will take 3-4months. In the meantime we should look into simplifying our chrome to not feature as much expensive CSS.

Longer term, Frank will look into reimplementing the tab bar in pure HTML  instead of XUL to maximize responsiveness.

CC/GC Pauses

Incremental GC should turned back on soon (bugs 750424, 750416). Olli relanded bug 747675 which should reduce CC times somewhat.

Kyle’s big memory leak fix from last week turned out to occasionally cause leaks where there were none before: see bug 751466.

Frontend

Tim spent the week in a seemingly infinite r?/r- cycle attempting to prove that one handle clicks on tabs without setTimeout, bug 743877. Tim also moved thumbnail storage away from network cache. This reduced cache contention (and browser freezes), bug 744388. Paulo continued nuking sync favicon api usage, bug 728168.

17 comments

  1. wrong bug number 3rd latest

  2. thanks, fixed it

  3. Bug 747675 should not affect to CC times at all.
    It should decrease max forgetSkippable times.

  4. But the memshrink guys have actually made some progress.

    I don’t feel like snappy has done anything.

    My firefox 12 install has been up for 4 days and as I type this it cannot keep up with my key strokes. It pauses for a few seconds at a time every few seconds.

    Linux, AMD Athlon(tm) II X4 630, 8gb of ram with over 4gb free (no swap usage). top says my CPUs are idle.

    Firefox is occasionally taking up to 5 seconds just to switch tabs.

    I suspect that the devs restart often enough that they don’t see how much firefox degrades over time.

    How can I help debug this?

  5. > Tim spent the week in a seemingly infinite r?/r- cycle attempting to prove that one handle clicks on tabs without setTimeout, bug 728168.
    Bug # is wrong for this one.

  6. Sorry, didn’t refresh on time.

  7. Takes a while to make significant changes. ff12 was early in the project, ff13 has the biggest batch of snappy changes so far. I think the issues you are describing will be solved with bug 715376, but that’s a bigger architectural issue. You can try the no gradients/borders build too. In a week or two we’ll deploy our internal profiler which will help users like yourself submit a snapshot of exactly what your firefox was doing.

  8. Can we implement the tab bar in HTML without breaking some addons?

  9. > Can we implement the tab bar in HTML without breaking some addons?

    No, but then XUL isn’t really a bottleneck here; the non-standard -moz-box display type potentially is. Hopefully we can address this by using the standard flexbox display type when it’s implemented in Gecko. This is a matter of CSS and entirely independent from whether the markup is XUL or HTML.

  10. I wonder the states of these 4 bugs, 3 of them seem close to land but had paused for a long time.
    Form history async
    https://bugzilla.mozilla.org/show_bug.cgi?id=692255

    Fast shutdown
    https://bugzilla.mozilla.org/show_bug.cgi?id=662444

    Cold startup optimization
    https://bugzilla.mozilla.org/show_bug.cgi?id=692255

    and Speedy Session Restore
    https://bugzilla.mozilla.org/show_bug.cgi?id=669034

  11. >Zizzle
    >Firefox is occasionally taking up to 5 seconds just to switch tabs.

    That’s may be due to garbage/cycle collection, especially if you have plugins like NoScript or Stylish installed. Go to about:config, set javascript.options.mem.log to true and check gc/cc times in Error Console.

  12. Cant wait for the internal profiler. This will solve all those mysterious slowdowns once and for all.

    What bothers me most is that Firefox freezes when loading a few tabs in background. The reason is probably the big cache lock, so why is this not the number 1 priority? Everybody hates Firefox because of this (…well and the tab switch, but this is being addressed) .

  13. Is there a bug for the implementation of the tab bar in HTML?

  14. I like to say something out of the way.
    1) After a long period, cairo recently released updated library, it has various performance ups, does introducing it in FF tree, somehow improve D2D performance issue..
    2) TI is disabled for Chrome, does it somehow improve it?

    taras can you guide me whether these can help?

  15. GC/CC pauses while watching videos (HTML5 and Flash) are another source of frustration when using Firefox. A number of fixes went into FF 14, and some more are going into FF 15 to alleviate this problem. When do you anticipate this problem to be mostly solved? What is the priority of this task over some of the other snappy initiatives?

    For reference, this problem does not surface when using IE, Chrome or Safari.

  16. marco, not yet
    Ahmad,
    1) no, the fixes involve moving away from cairo to a library better suited for web stuff
    2) TI is disabled for chrome because our primary focus for JS perf is for web content. The nature of chrome JS is that it interacts with native code differently and there is a lot less of it. It’s not productive to take away time from improving the web to speed up chrome when we can just fix the chrome code to do stuff more efficiently.

    Manoj, work is ongoing to fix html5 video pauses by end of Q2. Flash should follow quickly after as it can benefit from the same architecture improvements. Keep in mind this is an estimate.

  17. Thanks for the estimate Taras. This will improve the experience of watching cricket highlights on YouTube.