Tag Archives: fast

Things I’ve Learned This Week (May 18 – May 22, 2015)

You might have noticed that I had no “Things I’ve Learned This Week” post last week. Sorry about that – by the end of the week, I looked at my Evernote of “lessons from the week”, and it was empty. I’m certain I’d learned stuff, but I just failed to write it down. So I guess the lesson I learned last week was, always write down what you learn.

How to make your mozilla-central Mercurial clone work faster

I like Mercurial. I also like Git, but recently, I’ve gotten pretty used to Mercurial.

One complaint I hear over and over (and I’m guilty of it myself sometimes), is that “Mercurial is slow”. I’ve even experienced that slowness during some of my Joy of Coding episodes.

This past week, I was helping my awesome new intern get set up to tear into some e10s bugs, and at some point we went through this document to get her .hgrc all set up.

This document did not exist when I first started working with Mercurial – back then, I was using mq or sometimes pbranch, and grumbling about how I missed Git.

But there is some gold in this document.

gps has been doing some killer work documenting best practices with Mercurial, and this document is one of the results of his labour.

The part that’s really made the difference for me is the hgwatchman bit.

watchman is a tool that some folks at Facebook wrote to monitor changes in a folder. hgwatchman is an extension for Mercurial that takes advantage of watchman for a repository, smartly precomputing a bunch of stuff when the folder changes so that when you fire a command, like

hg status

It takes a fraction of the time it’d take without hgwatchman. A fraction.

Here’s how I set hgwatchman up on my MacBook (though you should probably go by the Mercurial for Mozillians doc as the official reference):

  1. Install watchman with brew: 
    brew install watchman
  2. Clone the hgwatchman extension to some folder that you can easily remember and build it: 
    hg clone https://bitbucket.org/facebook/hgwatchman
cd hgwatchman
make local
  3. Add the following lines to my user .hgrc: 
    [extensions]
hgwatchman = cloned-in-dir/hgwatchman/hgwatchman
  4. Make sure the extension is properly installed by running: 
    hg help extensions
  5. hgwatchman should be listed under “enabled extensions”. If it didn’t work, keep in mind that you want to target the hgwatchman directory
  6. And then in my mozilla-central .hg/.hgrc: 
    [watchman]
mode = on
  7. Boom, you’re done!

Congratulations, hg should feel snappier now!

Next step is to try out this chg thing – though I’m having some issues still.

Build Thunderbird Faster on Windows

There’s no denying it: the vast majority of Thunderbird users are using some flavour of Windows.

So it’s a bit strange that I do most of my development on Linux, and use Thunderbird most regularly on Mac OSX.

Therefore, I’ve recently gotten a hold of a new, super-powerful Windows 7 box.  Furthermore, in an effort to better understand what my users go through and experience, I’ll also be using Thunderbird on Windows as my primary mechanism for reading my mail.

So that’s all good, but there’s one problem:  building Thunderbird on Windows takes forever.

But it doesn’t have to.

So the Simple Build Instructions for Thunderbird instructs developers to get the MozillaBuild package, which includes a bunch of the tools you need to get Mozilla stuff up and building on Windows.  One of those tools is “make“, which is a tool that originates from the world of UNIX and Linux.

The problem with the make included with MozillaBuild is that it doesn’t take advantage of multiple processor cores on Windows.  So even if you have a crazy-powerful 8-core machine, when you just use the vanilla “make -f client.mk” command, you’re only going to be using one of your cores.

Enter pymake.  Pymake is a Mozilla-maintained mostly-compatible implementation of make in Python.  The advantage?  On Windows, we can finally use all of our cores.

So here’s how to set that up.

  1. I assume you’ve followed the instructions for setting up your Windows build environment, laid out here.
  2. I also assume you’ve checked out a copy of comm-central, have set up your .mozconfig, and have run “python client.py checkout” to grab Gecko, etc.
  3. If your Windows username has a space in it, like “Mike Conley”, you might want to create a new Windows account for the stuff we’re about to do.  I use “mconley”.
  4. You’re going to want to alias pymake – open up an editor, and create a file called .profile under C:/Users/[username]/  (I assume you’re on the C drive anyhow, and are using Windows 7)
  5. In that .profile file, put in the following line:   alias pymake=/c/Users/[username]/[path to comm-central]/mozilla/build/pymake/make.py
  6. Restart your shell, and ensure there are no errors in the first couple of lines that spring up at the top.  If you type pymake, it should say towards the bottom “No makefile found”.
  7. Go to the parent of your comm-central directory, and create a new directory for your obj-dir (where your binaries and executable will eventually end up).\
  8. In that directory, run the command:  “../comm-central/configure” – so we’re invoking the configure within the comm-central directory, but within the obj-dir folder we created
  9. The configure might fail while looking for the compiler.  Just try it again until it works.  *sigh*.
  10. Once the configure command is done, within your obj-dir folder, type:   pymake -sj4 (or 8, if you have 8 cores)

And blam, now you’re cookin’!

I can get a debug build done, from scratch, in about 22 minutes.  Woo!

UPDATE

You can also replace steps 8 – 10 with the following:

  1. In your objdir, type:  MOZCONFIG=../srcdir/.mozconfig pymake -sj6 -f ../srcdir/client.mk
  2. Eat sandwich while build completes