29
May 12

Snappy, May 24 – meetingless

Frank and Jared are aiming to have the Australis theme up for review next week in bug 732583. There are no computed borders or gradients in the redesign, so it will be faster.  The current theme generates new borders/gradients on every tab interaction, which is very inefficient. Bas is working on fixing our graphics backend to render borders/gradients more efficiently in bug 750871.

Wlad spotted some unintended bloat in the addon database in bug 752868. Blair fixed it, this should speed up startup and other addon manager interactions.

Bill did some further IGC fixes: bug 757483, bug 754588, bug 756732, bug 731423.

We started a new project to let Firefox diagnose common Windows/etc misconfiguration issues that severely impact Firefox performance. Our new intern, Nicholas, is working on this in bug 684646. The immediate plan is to release an addon that detects when Firefox startup is unusually slow, checks for known Windows issues and pops up a link to a Mozilla support article on how to fix the problem. If this turns out to be successful, we’ll integrate this functionality into Firefox.

The gecko profiler is now ready for general consumption. See Benoit’s announcement. This will allow users running  the profiling variant of Firefox nightly builds to capture/report performance problems in a way that developers can act on. I suspect that Benoit will blog about this.

Update: I originally linked the wrong bug for windows misconfiguration detection.


22
May 12

Give DXR a try

At Mozilla we have a long history of using MXR for looking up and discussing source code. Unfortunately MXR is an unlovable mess of Perl and a crappy (in terms of performance and license) text indexing engine that is glimpse. It is dead because nobody wants to work on it.

DXR is a semantically-aware successor to MXR. Semantic information is extracted from LLVM during compilation. This makes it possible to do searches like derived:nsIFile. DXR uses a modern Full Text Search engine for text searches, so it should be much faster than MXR. There is a test instance at dxr.mozilla.org, please give it a try. The homepage lists sample searches you can do.

DXR is written in Python. It uses an SQLite database + FTS index as a backend. Useful semantic information is extracted from the source via a Clang LLVM plugin. Checkout the source code at github.

DXR should be getting close to feature parity with MXR. Give it a try and let me know of any bugs/missing features you encounter (or submit a patch!). I realize that people have gotten used to various MXR quirks and that it can be stressful to switch to a new code indexer while trying to get stuff done, but MXR IS DEAD. We need to move on. Mozilla is complex, finding relevant code can take quite a while, especially for new contributors. Using a smarter indexer should save time, reduce frustration and free up a few developer-years to make Firefox better.

We have lots of ideas for DXR, but first we need to ensure it is a suitable replacement for MXR. Take DXR for a spin!


21
May 12

Snappy, May 17 – Physical Room Edition

Misc

This was an unusual meeting for the Snappy project: everybody was in the same physical room (though someone dialed in 5min before the end). I love the distributed nature of Mozilla, but it’s nice to have everybody in the same room for a change.

Vlad did some super-slow-startup investigation. We have even more evidence that loading pages before the UI is up is a bad idea: bug 715402.

Jet sped up browser chrome by converting SVG masks to clip-paths: bug 752918. With a name like that, how can he not work on performance bugs :)

The necko team is looking for feedback on test builds that reduce cache-related pauses on the main thread. If you suffer from cache-related lag, give these a spin: bug 722034.

Benoit made our profiling builds useful on Linux, Android (in addition to Windows, Mac64). Work is happening on extending our debug protocol with profiling abilities. Unfortunately I do not have bug #s to link to. The Windows symbol server is almost done with security review so it can be exposed to the web. For more profiler details see bugs: 753588, 751355, 751355, 751034, 751779.

Rafael is getting close to calling exit(0) in bug 662444. Much work remains, it’ll be the most significant change since we embarked on this project almost a year ago. Our current application shutdown situation is not pretty.

GC/CC

Bill landed incremental GC again, it promptly bounced out: bug 735099.

We now do compartmental GC more often: bug 716014.

Andrew is working on reducing CC overhead (by 80% in his benchmark) when closing tabs: bug 754495.

LagBlock Plus

I’ve been running Wlad’s extension for over a week now. The browser is so much more pleasant now. Background tabs used to make text-entry a painful process. Can’t wait until we can approach a similar level of responsiveness by scheduling background tab events more intelligently.

I feel that letting tabs run out of control is a serious misfeature in the current web ‘architecture’. Modern OSes require background apps to suspend (ie Android, iOS). It is about time that browsers forced a similar behavior: ie bug 675539. Web developers should be given a way to request to run background tasks and users should be able to veto that.


21
May 12

Snappy Workweek

Workweek

The perf team + Lawrence held a snappy workweek at the Mozilla HQ last week. We spent most of the week meeting with various people involved with the Snappy project. I expect lots of good things to happen in the near future.

The most immediate outcome of all of these meetings was the public unveiling of our telemetry dashboards. See Lawrence’s post on how to log in with your persona account. We started work on telemetry about a year ago, felt great to finally reach this milestone. Lots of work remains on UI polish, data validation, etc. Telemetry is our primary mechanism for gathering snappy performance data. Every telemetry infrastructure improvement leads to better snappy decisions.

Additionally we discussed Australis theme work (how it should be faster than existing theme), dom event scheduling, main thread io work, feasibility of switching to an FTS backend for places, etc.

Vlad wrote some good posts on analyzing startup and other data exposed by about:telemetry. Planet Mozilla could use more technical posts like that.

 

 


14
May 12

Snappy, May 10: Suspending activity in background tabs

Tim landed a fix to avoid setTimeout()s when handling tab clicks: bug 743877. This should significantly improve our tab strip responsiveness.

Incremental GC is making progress towards being turned on by default again: bugs 750959, 752098.

There was also progress on cancellable SQL (bug 722243). This should result in faster shutdown.

Progress was made towards fixing cache locking, bug 722034.

Lawrence posted a summary of snappy work that went into Firefox 13.

LagBlock Plus

Some of the lag in Firefox is caused by background tabs processing timeouts willy-nilly. We are working on teaching Firefox to cope with overactive background tabs in bug 715376. The plan is to allow Firefox to throttle/group background events, especially in tabs that are CPU hogs.

To help us along, the author of Adblock Plus released an experimental addon that freezes activity in background tabs. Since this addon halts all background tab activity, it is a useful gauge of baseline performance that we’ll try to get asymptotically close to. It is also helpful for isolating responsiveness issues that are not caused by background tabs.

 

 


03
May 12

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.


01
May 12

Pushing the borders [out] of Firefox performance

As I mentioned before, we are back to investigating some gfx deceleration issues. Preliminary investigation shows that our border+gradient code is inefficient and since Firefox uses these features heavily, we get some epic slowdowns when tab switching.

To test out this theory Bas put up a test build that simply does not draw gradients or borders. See bug 75087  for a screenshot demonstrating drastic reduction in browser attractiveness. There is also a test build for people suffering from slow drawing to try out.