fishsoup

One of the big goals of the GNOME 3 Shell is to use animation and visual effects for positive good. An animation explains to the user what the connection is between point A and point B. For this to work, the animation has to be smooth – it can’t be a jerky sequence of disconnected frames. Performance matters.

Over the last 18 months we’ve done a fair bit of work on performance – everything from fixing problems with AGP memory caching in the radeon kernel drivers to to moving tests for whether recent files are still there to a separate thread. But this work was ad-hoc and unsystematic. There was no way to see if shell performance got better or worse over time. To compare the performance of two different systems. Or even to tell in a rigorous way whether an optimization that seemed to make sense actual improved things. Over the last few weeks I’ve been working to correct this; to get hard, repeatable numbers that represent how well the shell is performing.

The core of the GNOME Shell performance framework is the event log. When event logging is enabled, all sorts of different types of events are logged: when painting of a frame begins, when painting of a frame ends, when the user enters the overview, and so forth. The log is stored in a compact format (as little as 6 bytes per event), so can be recorded with very little overhead. It doesn’t significantly affect performance.

The other thing that is recorded in the event log is statistics. A statistic is some measurement about the current state: for example, how many bytes of memory have been allocated. Every few seconds, registered statistics are polled and written to the event log as a special event type. Statistics collection can also be triggered manually.

Once we have an event log recorded, we can analyze it to determine metrics. We can measure the latency between clicking on the activities overview button and the first frame of the zoom animation. We can see how many bytes are leaked each time the user goes to the overview by comparing the memory usage before and after. Since we want to measure exactly the same conditions every time, we don’t want to analyze a performance log generated by the user actually doing stuff; instead we script the operation of the shell from Javascript. You can see how this looks by looking at the run() function in js/perf/core.js. The rest of this performance script contains the logic to compute the metrics when the recorded event log is replayed (For example, during replay the script_overviewShowDone() function is called when replaying a script.overviewShowDone event.)

Running gnome-shell --replace --perf=core produces a summary of the computed metrics that looks, in part, like:

# Additional malloc'ed bytes the second time the overview is shown
leakedAfterOverview 83200
# Time to first frame after triggering overview, first time
overviewLatencyFirst 192482
# Time to first frame after triggering overview, second time
overviewLatencySubsequent 66838


(The times are in microseconds.) Being able to get these numbers for a particular build of the shell is good, but what we really want to be able to do is compare these numbers over lots of systems over time. So, there’s also a website shell-perf.gnome.org where statistics can be uploaded.

(The way that uploading works is that after registering a system on the site, you are mailed instructions about how to create a ~/.config/gnome-shell/perf.ini with an appropriate secret key, and the --perf-upload option uploads the report. Please only do this with Git builds of gnome-shell for now – there are some updates to the metrics even since the 2.29.2 release yesterday.)

If you browse around the site, you’ll see that you can look at the recorded metrics for different systems or for an individual system over time. You can also look at a specific uploaded report. An example:

I should point out, since it’s not very obvious, that navigation to individual reports is by clicking on the report headers in the system view. In the report view, you can see the details of the uploaded metrics. But you also can see the entire original event log! (The event log browser is using the HTML canvas – I’ve tested it in Firefox and Epiphany – it probably works in most browsers that GNOME developers are likely to be using.) Having the event log means that if an anomalous performance report is uploaded we can actually dig in and see more about what’s going on.

OK, time to make good on my promise to write about Splinter some more and show it off. The basic idea of Splinter (hinted at in my last post) is that instead of doing patch review as a completely new system and building all the infrastructure from scratch, it should be possible to do the kind of interactive patch review featured by systems like Review Board or Rietveld directly on patches attached to Bugzilla.

When you visit Splinter’s display of patch attachment, you see a standard two-column patch display like:

Any coments that people have previously made will show up inline. If you have comments to make yourself, you can double-click on a line and an editor will open where you can type the new comment:

I put up a (read-only) demo instance of Splinter where you can try this out live.

When you publish your review, it will be published as a comment in Bugzilla that looks (in part) something like:

::: js/ui/lookingGlass.js
@@ -355,3 +355,3 @@
             inspector.connect('closed', Lang.bind(this, function() {
                 this.actor.show();
-                global.stage.set_key_focus(this._entry);
+                Main.acquireKeyboardFocusStack(this._entry);

I'm not sure why we are setting the keyboard focus (either way) when the
inspector is closed, but using a stack-based acquire() seems
definitely wrong.

The idea of the format is to be readable if someone is just reading the comments in the review or in emails from Bugzilla, while still being parseable by Splinter for inline display.

A neat feature of Splinter is it uses the new DOM Storage mechanism to save in-progress reviews. You can leave the page for a review and come back to it any time and your review will be as you left it. (This requires a brand new browser, like Firefox 3.5.)

Using it yourself

Assuming that there’s interest, I’d like to make this available on bugzilla.gnome.org. The first step would be just having it there behind the scenes if you know the URL. The second step would be to write a small Bugzilla extension to link to add links to Splinter from review comments and from the attachments section.

But you don’t need to wait for this. If the above is something that you want now, then you can clone it from git://git.fishsoup.net/splinter (browse, README). In the proxy/ subdirectory, there’s a README file that describes how to run a local proxy server pointed to a Bugzilla instance. It’s really easy. Then connect to:

http://127.0.0.1:23080/index.html

in your web browser. Some aspects are a bit obscure as of yet; for example if posting a review hits “a mid-air conflict” then it will fail and you need to reload the page (safe because of the use of DOM Storage!) and try again. But it’s definitely usable.

Behind the scenes

The most interesting thing about Splinter is that the server referred to above is just a proxy server. The only reason that it is there at all is to safely get around cross-site-scripting restrictions; there’s no server side component at all. Instead, the Javascript code of Splinter uses the existing exposed web interfaces of Bugzilla (and your existing Bugzilla login credentials) to get information about the bug and post reviews back. Everything – parsing the patch files, building the display – is done in Javascript in your web browser.

One of the main reasons for doing it this way was language choice. I’m doing a lot of Javascript coding for gnome-shell, so its very much at my fingertips. And there was going to be Javascript and DOM manipulation in any case – I wanted a modern interactive interface for editing reviews. If I was going to write a server side component, I’d need to do it in Perl to integrate nicely with the Bugzilla environment, but my Perl is distinctly rusty. Everything in Javascript side-stepped that issue.

The Javascript approach also is easy for development – you don’t need a test Bugzilla instance to work on, you can just hack on the Javascript and HTML files, and use the proxy server to run your changes against a public Bugzilla instance.

The Javascript code uses JQuery extensively. It’s my second project using it, and I’m liking it a lot. In some ways, it’s really a meta-language on top of Javascript, but it gives a lot of power compactly and readably. (Readably if you don’t get too clever with it.) The source code also contains a SpiderMonkey-based test harness so that I could write tests for the non-interactive parts like parsing patches and run ‘make check’.

Future

Splinter is never going to be as nice for the single task of patch review as Review Board. But there’s quite a bit of low-hanging fruit to make it better. In addition to the small Bugzilla extension mentioned above, other things I’m thinking of include: better control of how much context is shown with a comment. A collapsed view of a review that just shows the review and the sections being commented on. A threaded display of the attachments of a bug showing their relationship to each other and the reviews on each version. The ability to add extra context around a particular section of a patch.