Feb 12

At BetaGroup in Brussels

As the outside temperature reached -10C, the DIY heating system at hackerspace.be proved insufficient. On Wednesday the Perf/Snappy workweek was relocated to BetaGroup Coworking Brussels. We’ll be here until FOSDEM.

Betagroup Coworking Brussels is an industrial-strength coworking space with lots of desk space, internet, kitchen, ping-pong and a bunch of heavy metal…

Jan 12

fast DXR

DXR is now uber-fast. See bottom of search pages for timing info. Give it a try. We have a few more bugs to fix before we jump into fixing the UI.

Jan 12

At hackerspace.be getting ready for FOSDEM


We just started our Perf/Snappy workweek in Brussels, Belgium. hackerspace.be let us use their space. If you are also performance hacker in the area, why not drop in for some beers?

See Dietrich’s post for more details.

Dec 11

Growing reviewers

One of the challenges of a growing organization is that people become managers and have less time for coding. A scary proportion of module owners are managers now.

We were discussing this with Dietrich and he came up with a really simple solution: module owner’s entire team should be able to review patches for that module. Obviously new people can’t review every little detail, for those they can pass the buck to their manager(and learn in the process). I really like the new Firefox review policy of having a large set of candidates for reviews who have an option of passing the patch along.

Perhaps bugzilla can change r?:taras queries into r?:taras+his+team and do this automagically.

Dec 11

24-hour reviews

I would like to see Firefox developers switch to 24hour review turn-around times. Note that in my definition review turn-around means any of the following:

  • r+/r-
  • unset/reassign r? to someone else

It is ridiculous in our recent faster release cycle if a patch takes half (or more) of the cycle loitering in the review queue. I believe that a shorter review cycle is the simplest way to accelerate Firefox evolution.

I view fast review times as a matter of respect. Posting a patch usually requires a significant time/effort commitment, reviewers should act appropriately. There is no bigger buzzkill than having your work pushed back to the bottom of somebody’s TODO list like some annoying chore.

As far as I can tell there are 3 main reasons* that lead to long review times:

1) People like gavin, bz, dbaron having disproportionally high review loads. We need a process to hand-off patches to other reviewers. High-load people shouldn’t shy away from passing on the r? to someone else when possible.
2) Bugzilla-fobic people (like myself) loosing track of bugzilla r? requests due to not having bugzilla whines setup. Bugzilla whines should be enabled by default.
3) Bad review habits.  I met a number of Mozilla developers that like to batch their reviews up and then do them all on a single weekday. Please stop, you are killing all kinds of coding momentum/fun/etc.Lets make it our policy to set aside time every day to clear the review queue.

Clearly people with existing backlogs will take a while to catch up, but most MoCo employees should be capable of this.
I have yet to hear a good reason against doing daily reviews.

It has been a few months since I proposed this on dev.platform.  I have tried to live by the 24hour rule, I think a few others tried this too. I find that morning bugzilla r? whines work best for me. I still occasionally loose track of a patch for a few days, but nobody is perfect. I think people appreciate fast reviews, but nobody thanked me yet.

Dec 6 Update: My goal is to have *some* response within 24hours with an ETA for next followup in the worst case.

Oct 11

Emacs > CMD.EXE

Mozilla requires a unixy dev environment. Makefiles, hg, patches, ssh, irc, etc. Unfortunately Windows lacks in terminal abilities. No tabs, crappy cut/paste, limited size, slow, etc.

Emacs has a wonderful shell-mode(ie my bottom-left buffer). This means that windows can now do proper command history, cut/paste & use multiple emacs buffers(like tabs in a more sane terminal). Like all good features in emacs, out of the box shell mode is pretty busted, but can be fixed to default to bash. Microsoft also provides a very nice fixed width font for emacs. I keep my emacs config in hg. I really appreciate the operating system that is emacs.

Oct 11

Alternative to the Indignity of Dealing with the Error Console

The JavaScript error console is a relic from the Mozilla stone age. There are two problems with it:

  1. It lives in a separate window
  2. It is not helpful

I’ve been drooling over the new Firefox Web Console, but unfortunately it doesn’t have chrome privs [yet?] so it isn’t a replacement for the error console since it operates with privileges of the webpage displayed. Turns out I was 2 steps away from nirvana:

  1. Navigate to chrome://global/content/console.xul.
  2. Menu -> “Web Developer” -> “Web Console”

Turns out that one can load a url with chrome privs (about:memory works too) and the web console becomes a very helpful [with autocompletion, less noise, etc) tool for typing Components.interfaces…


Scratchpad can also do this sans autocompletion, see Rob’s comment below.

Oct 11


Linux Plumbers

A few of us attend LinuxPlumbers last month, I gave talk. Basic summary: kernel + toolchain could add a few straight-forward features to make Firefox and other apps start faster and use less memory.

Performance Team

I am no longer alone on my quest of performance whack-a-mole. Since spring I’ve been growing a team of extremely talented people to help make Firefox faster and slimmer. As a manager I do more people tasks now, so I have less ” ____ sucks” blog posts to write. We are currently working on massively speeding up Fennec startup via incremental decompression (sort of like an efficient UPX for android), fixing SQLite + other IO usage in Firefox, reordering binaries for faster startup, faster shutdown. The idea is to focus on all areas of browser performance other than rendering the web (for now).

Performance Help

“Perf work is cool, but I wouldn’t know where to start with finding a good first perf-bug” <– is this you? Would any of my readers be interested in a roundup of next set of “low hanging fruit” perf-improvements to be had?

Example bugs:

Sep 11

Firefox 7: Telemetry

Firefox 7 marks a turning point in how we measure Firefox performance. Traditionally we measured Firefox performance on individual developer machines and our build & release infrastructure. However it turns out synthetic benchmarks do not correspond to real-world Firefox usage: it is difficult to model a “typical” computer in a lab environment. Surprisingly slow consumer hardware, changes in usage patterns, preinstalled bloatware all affect Firefox performance in surprising ways.

Firefox 7 telemetry will prompt users to opt-in to reporting performance data to Mozilla. This data will supplement our existing benchmarking infrastructure to help us optimize future Firefox releases. Telemetry performance metrics are very lightweight and will not negatively impact Firefox performance.

In addition to transmitting data via SSL, Mozilla privacy team worked tirelessly to ensure that no personally-identifiable information is sent via telemetry. Whereas many other software projects stamp this kind of data with a unique per-user id, we opted for a per-session id which is reset every time the browser restarts. Telemetry is also disabled while in private-browsing mode.

The following telemetry data will be gathered in Firefox 7:

  • Memory usage
  • CPU core count
  • Cycle collection times
  • Startup speed

Use the about:telemetry extension to check on your browser performance. The following screenshot shows how to enable telemetry:

I’m very excited that Firefox finally joins the ranks of cars, airplanes and other software projects in making performance decisions based on real evidence gathered in the wild.


Aug 11

Ride to The Coast

I like having guests who bike. So when Brian came over I decided this would be a great opportunity to explore going to the coast and back by bike (velodirt style). The following is a map of our trip (190miles, 2 nights).

The gravel roads were somewhat challenging. It was hard to climb in the heat so at times we had to push our bikes.

Things got more unpleasant when we encountered loose gravel by Tillamook which sent Brian sliding over the edge :(

Amazingly he got off without a single scratch (type-inference will go on!).

Eventually we got to Cape Lookout.

The next day we biked to and spent the night in Nehalem Bay.

Then it was time to head back :(

On the way back we did some more gravel roads, this time they were really nice. The road took us through a berry-laden forest and rewarded us with some pretty awesome views.

(If you squint you can see Brian)


The thing to keep in mind about gravel roads is that they like to get out of sync with the maps. We had to reroute due to roads going in a different direction, and due to various kinds of deadends.

In one extreme case a road was clearly on the map, but had a “DEAD END” sign on it. Which got us thinking “is this a dead end for cars or is it for real?”. After some climbing, the gravel road reduced to a nice forest path.

Further on it became obvious that someone tried hard to kill this road. Some road hater put up over a dozen tree pile barriers, with some reaching my height.

Turned out the road did indeed go through. Perhaps some day someone will start a cyclocross race dedicated to bringing this road back :)

The last highlight of the trip was this delicious-looking buffalo herd.

I love cycling in Oregon.