Category Archives: Computer Science

Australis Performance Post-mortem Part 1: Where We Started

Getting to the merge

Last Monday, November 18th, Australis merged into our Nightly release channel, meaning lots of people are getting to try it and give us feedback. It’s been an exciting week, and we’re all very pleased with the response so far!

Up until then, if you wanted to try Australis, you had to use the Nightlies from the UX branch. If you followed along on the UX branch, you’ll know that the tabs and the customization work have been in a pretty steady state for the last few months.

So what was the hold up? Why did it take so long to get to the merge?

Gather round folks, I have a story to tell.

Some terminology

I’m going to be batting around a few terms here, and some people will understand them right away, and some people won’t, so I’ll just spell them out here, in no particular order:

Australis
If at this point you’re still not sure what I mean by Australis, you might want to check out this blog post and the accompanying video.
mozilla-central
mozilla-central, in this instance, refers to code that did not have the Australis changes in them. In the grand scheme of things, mozilla-central was where non-Australis code went, and then we’d merge those changes into the UX branch.
UX branch
The UX branch was where we were storing all of the Australis code.
Talos
Talos is a series of tests that we can run against a build of Firefox to measure the performance of different things – for example, how long it takes for a window to be opened. As of this writing, Talos tests for Desktop Firefox are run on Ubuntu Linux 12.04, OS X (10.6, 10.7 and 10.8), and Windows (XP, 7 and 8).

Where we started from

Let’s rewind a bunch of months. Let’s go to about early June, 2013. At this time, the curvy tab work was essentially finished on Windows, and had been ported to OS X and Linux. The customization code was still being hacked on, but we felt like we were in a pretty decent place – the team felt like we were ready to merge into mozilla-central to get some real user feedback and testing.

The problem was that up until that point, we hadn’t been running the Talos tests on the UX Branch, which means we didn’t really have a good idea about how we were performing in comparison to mozilla-central.

And then we turned the Talos tests on. Data started to flow in, and it wasn’t happy data. In particular, we were regressing pretty badly on two tests: ts_paint and tpaint.

ts_paint
this test measures how long it takes for Firefox to paint the first window on startup.
tpaint
this test measures how long it takes for Firefox to paint a newly opened window from a Firefox that is already running

Before I show you this data, I should clear some things up:  as mentioned above, we run these Talos tests on a bunch of operating systems, and a variety of operating system versions. I don’t want to bog this post down with too many charts, so I’m going to extract a chart for each operating system, and forgo breaking it down by operating system version. Suffice it to say that the regressions were pretty consistent from version to version.

Also, in each of these graphs, green represents mozilla-central, and red represents the UX branch. Up is bad (slower). Down is good (faster).

Anyhow, here’s what we saw:

ts_paint

Windows XP - ts_paint regression

Windows XP – ts_paint regression

Linux 32 - ts_paint regression

Ubuntu 12.04 – ts_paint regression

OSX 10.6 - ts_paint regression

OSX 10.6 – ts_paint regression

tpaint

Windows XP - tpaint regression

Windows XP – tpaint regression

Linux 32 - tpaint regression

Ubuntu 12.04 – tpaint regression

OSX 10.6 - tpaint regression

OSX 10.6 – tpaint regression

Ouch

The team has been working like crazy to make Firefox look and feel faster. Hitting a regression like this blows.

It’s also flat out unacceptable to have a regression like this unless there’s a really really good reason for it.

So we had to investigate. What was making us slow? What had we done wrong?

Find out in Part 2.

ScummVM ported to HTML5?

This was just brought to my attention, and I’m pretty stoked! I haven’t actually looked at the source or done much in the way of investigation, but if it’s legit, then this is really, really exciting. 🙂

Maybe not as exciting as porting Unreal 3 to the web, but, well, I’m old-school. 😀

UPDATED: Thanks everybody for alerting me to the broken link. Fixed it now.

Australis Curvy Tabs: More Progress!

I wrote a while back about how Matt, Avi Halachmi and I have been ironing out performance problems with the Australis curvy tabs.

Well, it looks like that work is finally paying off.

Our SVG usage seemed to be the big slow-poke, and switching to PNGs gave us the boost that we needed.

But enough squawking, let’s see some charts.

Before Optimizations

Let’s compare – here’s a chart showing the difference between pre-curves and post-curves, before our optimizations:

A graph showing Australis curves performance measurements before optimizations

Here’s the before shot

Note: it’s been a while since I’ve done data visualization work. I think the last time I did this was in grad school. So there might be way better ways of visualizing this data, but I just chose the easiest chart I could manage with Google Docs. Just go with it.

Let me describe what you’re seeing here – we take samples every time a tab opens, and every time a tab closes*. What we’re measuring is the interval time (how long it takes before we start drawing the next frame), and the paint time (how long it takes to actually draw a frame).

The blue bars represent the performance measurements we took on a build using the default theme.  The red bars represent the performance measurements we took using the Australis curvy tabs.

This is where my graph could probably be clearer – in each group of four bars, the left two represent interval times, and the right two represent paint times.

So, hand-wavey interpretation – we regressed in terms of performance in both painting, and frame intervals, for tab opening and closing.

So that’s what we started with. And then we did our optimizations. So where did we get to?

After Optimizations

A graph showing Australis curves performance measurements after optimizations

Here’s the after shot!

The red bars shrunk, meaning that we got faster for both interval and paint times. In fact, for tab close, we beat the old theme! And we’re really super-close for tab open.

Pretty good!

Curvy tabs for all

Last night, Matt landed our optimization patches, as well as preliminary curvy tab work for OSX* and Linux GTK on our UX branch. So, if you’re on the UX branch (and why aren’t you?), you should be receiving a build soon with some curvy tabs. They’re not perfect, not by a long shot, but we’re getting into the polish stage now, which is good.

* Some notes on our measuring methodology. All tests were performed on a low-powered Acer Aspire One netbook. Intel Atom n450 processor (1.66Ghz), 1GB of RAM, running Windows 7. The device has no graphics acceleration support. We also switched to the classic theme to avoid glass. Avi wrote a patch that opened and closed a tab 15 times, and averaging the frame intervals and paint times for each frame. Those were averaged over the 15 openings and closings. We then ran that test 4 times, giving the machine time to “relax” in between, and averaged our results.

* We don’t have hi-dpi support yet, so if you’re on a Mac with a Retina display, your curves might be fuzzy. We’re working on it.

Rambling about a new Address Book for Thunderbird

Hey all.

I’ve been pretty bad about talking about the address book. Sorry about that. I’ve been pretty busy helping to get Instant Messaging shipped for TB 15.

But with IM polished off, I’ve (once again) started refocusing my attention to the address book.

So where am I?

The Ensemble Project

In short, I’m writing an add-on to experiment with approaches to a new address book. I’m calling it “Thunderbird Ensemble”, because every project needs a cool code name.

The add-on is in its very very early stages. Nothing is usable. Nothing is stable or guaranteed. There’s no UI yet, but there are some tests.

You can track my progress here.

Here are some highlights, implementation details and unstructured thoughts about the add-on, and where I’m going with it:

SQLite Storage Back-end

I’ve chosen to use SQLite (via mozStorage) for the contact database. I was originally toying with using indexedDB, but it’s lack of support for substring searches (which is necessary for things like auto-complete) wasn’t very appealing. I briefly toyed with throwing my own indexing layer on TOP of indexedDB, and then I realized that I was probably reinventing the wheel.

So SQLite it is!

Diffs, Diffs Everywhere

Contact records are a representation of the fields and meta data about a contact. My add-on will be able to calculate diffs between records, and those diffs can be applied on top of records to make changes.

So, for example, suppose I decide to make some changes to a contact – I add some email addresses, remove a phone number, and change a birthday. I’m effectively creating a diff.

Now we apply the diff on top of the original contact, and send the resulting contact record to the datastore for storage.

If the storage happens to be on the network, and the original record we applied the diff on to was out of date, we should get a fresh copy of the contact record, apply the diff, and try again.

Conflict Resolution

With diffs comes conflicts resolution – but conflict resolution is never a pleasant experience, and I’d like the user to not have to deal with that if possible.

My solution is to just be optimistic – if a diff is asking to remove something that isn’t there, great! Mission accomplished! If the diff is adding something that already exists, no problem! We skip!

And for things that get changed, like birthdays, we simply say that the last writer wins.

Maybe that’s naive, but that’s the approach that I’m taking.

What do I have?

I can create contact records, diff them, apply diffs, and “merge” two records together. And I have tests for all of that work.

I’ve got the start of the SQLite backend working (basically, we can set up the database…but that’s it.)

I’m currently working on importing old Thunderbird contacts into Ensemble’s notion of contact records.

After that, I’ll work on getting them written to the database.

Comments? Questions? Complaints? Ask them here. It’s still really early on in the process, but if you find bugs in my code, please file issues on GitHub.