After six months of working on Tracemonkey, I’ve built up a particular workflow — how I use Mercurial, arrange my workspaces, run tests, and commit code.\u00a0 I thought it would be worth describing this in case it helps other developers improve their workflow, or perhaps so they can give me ideas on how to improve my own workflow.<\/p>\n
I have two machines, an Ubuntu Linux desktop and a Mac laptop.\u00a0 For both machines I use the same workspace structure.\u00a0 All my Mozilla work is in a directory ~\/moz\/.\u00a0 At any one time I have up to 10 workspaces.\u00a0 ~\/moz\/ws0\/ always contains an unmodified clone of the tracemonkey repository, created like so:<\/p>\n
hg clone http:\/\/hg.mozilla.org\/tracemonkey\/ ~\/moz\/ws0<\/pre>\nWorkspaces ~\/moz\/ws1 through to ~\/moz\/ws9 are local clones of ~\/moz\/ws0\/ in which I make modifications.\u00a0 I create these workspaces like this:<\/p>\n
hg clone ~\/moz\/ws0 ~\/moz\/wsN<\/pre>\nLocal hg clones are much cheaper than ones done over the network.\u00a0 On my Linux box it takes about 45 seconds, on my Mac somewhere over 2 minutes;\u00a0 it seems that laptops have slower hard disks than desktops.\u00a0 In comparison, cloning hg.mozilla.org\/tracemonkey\/ can take anywhere from 5 to 30 minutes or more (I don’t know why there’s so much variation there).<\/p>\n
I mostly work with the Javascript shell, called ‘js’, so I do most of my work in ~\/moz\/wsN\/js\/src\/.\u00a0 There are three ways I commonly build ‘js’.<\/p>\n
I have a number of bash aliases I use to move around these directories:<\/p>\n
alias m=\"cd ~\/moz\/\"\r\nalias m0=\"cd ~\/moz\/ws0\/\"\r\nalias j0=\"cd ~\/moz\/ws0\/js\/src\/\"\r\nalias j0d=\"cd ~\/moz\/ws0\/js\/src\/debug\/\"\r\nalias j0o=\"cd ~\/moz\/ws0\/js\/src\/opt\/\"<\/pre>\nand so on for the remaining workspaces ws1 through ws9.\u00a0 I have a common bash config file that I use on both my machines;\u00a0 whenever I change it I copy it to the other machine.\u00a0 This is a manual process, which is not ideal, but in practice it works well enough.<\/p>\n
I find nine workspaces for making changes is enough to cover everything I’m doing;\u00a0 if I find myself needing more it’s because some of the existing ones have stagnated and I need to do some cleaning up.<\/p>\n
Building ‘js’<\/h3>\n
I have three scripts, js_conf_debug, js_conf_opt, js_conf_optg, which configure and build from scratch.\u00a0 Here is js_conf_debug, the others are similar:<\/p>\n
#! \/bin\/sh\r\n\r\nif [ -z $1 ] ; then\r\n echo \"usage: $0 <dirname>\"\r\nelif [ -d $1 ] ; then\r\n echo \"directory $1 already exists\"\r\nelse\r\n autoconf2.13\r\n mkdir $1\r\n cd $1\r\n CC='gcc -m32' CXX='g++ -m32' AR=ar ..\/configure \\\r\n --enable-debug --disable-optimize --target=i686-pc-linux-gnu\r\n make --quiet -j 2\r\nfi<\/pre>\nThese are scripts rather than bash aliases or functions because they are quite different on the Linux machine and the Mac.<\/p>\n
I also have this alias for incremental builds:<\/p>\n
alias mq=\"make --quiet -j 2\"<\/pre>\nTesting ‘js’<\/h3>\n
The program I run most is trace-test.js.\u00a0 So much so that I have more aliases for it:<\/p>\n
alias jsott=\"time opt\/js -j trace-test.js\"\r\nalias jsdtt=\"time debug\/js -j trace-test.js\"<\/pre>\nI don’t need an alias for the optg build because that’s only used with Cachegrind, which I run in a different way (see below).<\/p>\n
I run the JS unit test with the following script:<\/p>\n
function js_regtest\r\n{\r\n x=$1\r\n y=$2\r\n if [ -z $x ] || [ -z $y ] ; then\r\n echo \"usage: js_regtest <ws-number-1> <ws-number-2>\"\r\n else\r\n xdir=$HOME\/moz\/ws$x\/js\/src\/debug\r\n ydir=$HOME\/moz\/ws$y\/js\/src\/debug\r\n echo \"############################\"\r\n echo \"## COMPILING $xdir\"\r\n echo \"############################\"\r\n cd $xdir && mq\r\n echo \"############################\"\r\n echo \"## COMPILING $ydir\"\r\n echo \"############################\"\r\n cd $ydir && mq\r\n cd $ydir\/..\/..\/tests\r\n echo \"############################\"\r\n echo \"## TESTING $xdir\"\r\n echo \"############################\"\r\n time jsDriver.pl \\\r\n -k \\\r\n -e smdebug \\\r\n --opt '-j' \\\r\n -L spidermonkey-n.tests slow-n.tests \\\r\n -f base.html \\\r\n -s $xdir\/js && \\\r\n echo \"############################\"\r\n echo \"## TESTING $ydir\"\r\n echo \"############################\"\r\n time jsDriver.pl \\\r\n -k \\\r\n -e smdebug \\\r\n --opt '-j' \\\r\n -L spidermonkey-n.tests slow-n.tests \\\r\n -L base-failures.txt \\\r\n -s $ydir\/js\r\n fi\r\n}<\/pre>\nAn example invocation would be:<\/p>\n
js_regtest 0 3<\/pre>\nThe above invocation first ensures a debug ‘js’ is built in workspaces 0 and 3.\u00a0 Then it runs ~\/moz\/ws0\/js\/src\/debug\/js in order to get the baseline failures, which are put in base-failures.txt.\u00a0 Then it runs ~\/moz\/ws3\/js\/src\/debug\/js and compares the results against the baseline.\u00a0 The -L lines skip the tests that are really slow;\u00a0 without them it takes hours to run.\u00a0 I time each invocation just so I always know roughly how long it takes;\u00a0 it’s a bit over 10 minutes to do both runs.\u00a0 It assumes that workspace 0 and 3 correspond to the same hg revision;\u00a0 perhaps I could automate that to guarantee it but I haven’t (knowingly) got that wrong yet so haven’t bothered to do so.<\/p>\n
Timing ‘js’<\/h3>\n
I time ‘js’ by running SunSpider.\u00a0 I obtained it like so:<\/p>\n
svn http:\/\/svn.webkit.org\/repository\/webkit\/trunk\/SunSpider ~\/moz\/SunSpider<\/pre>\nI haven’t updated it in a while, I hope it hasn’t changed recently!<\/p>\n
I run it with this bash function:<\/p>\n
function my_sunspider\r\n{\r\n x=$1\r\n y=$2\r\n n=$3\r\n if [ -z $x ] || [ -z $y ] || [ -z $n ] ; then\r\n echo \"usage: my_sunspider <ws-number-1> <ws-number-2> <number-of-runs>\"\r\n else\r\n for i in $x $y ; do\r\n dir = $HOME\/moz\/ws$i\/js\/src\/opt\r\n cd $dir || exit 1\r\n make --quiet || exit 1\r\n cd ~\/moz\/SunSpider\r\n echo \"############################\"\r\n echo \"####### TESTING ws$i #######\"\r\n echo \"############################\"\r\n time sunspider --runs=$n --args='-j' --shell $dir\/js > opt$i\r\n done\r\n\r\n my_sunspider_compare_results $x $y\r\n fi\r\n}\r\n\r\nfunction my_sunspider_compare_results\r\n{\r\n x=$1\r\n y=$2\r\n if [ -z $x ] || [ -z $y ] ; then\r\n echo \"usage: my_sunspider_compare_results <ws-number-1> <ws-number-2>\"\r\n else\r\n sunspider-compare-results \\\r\n --shell $HOME\/moz\/ws$x\/js\/src\/opt\/js opt$x opt$y\r\n fi\r\n}<\/pre>\nAn invocation like this:<\/p>\n
my_sunspider 0 3 100<\/pre>\nwill ensure that optimised builds in both workspaces are present, and then compare them by doing SunSpider 100 runs.\u00a0 That usually gives what SunSpider claims as +\/-0.1% variation (I don’t believe it, though).\u00a0 On my Mac this takes about 3.5 minutes, and 100 runs is enough that the results are fairly reliable, certainly more so than the default of 10 runs.\u00a0 But when testing a performance-affecting change I like to do some timings, wait until a few more patches have landed in the tree, then update and rerun the timings — on my Mac I see variations of 5-10ms regularly due to minor code differences.\u00a0 Timing multiple versions like this gives me a better idea of whether a timing difference is real or not.\u00a0 Even then, it’s still not easy to know for sure, and this can be frustrating when trying to work out if an optimisation I applied is really giving a 5ms speed-up or not.<\/p>\n
On my Linux box, I have to use 1000 runs to get +\/-0.1% variation.\u00a0 This takes about 25 minutes, so I rarely do performance-related work on this machine.\u00a0 I don’t know why Linux causes greater timing variation.<\/p>\n
Profiling ‘js’ with Cachegrind<\/h3>\n
I run Cachegrind on ‘js’ running SunSpider with this bash function:<\/p>\n
function cg_sunspider\r\n{\r\n x=$1\r\n y=$2\r\n if [ -z $x ] || [ -z $y ] ; then\r\n echo \"usage: cg_sunspider <ws-number-1> <ws-number-2>\"\r\n else\r\n for i in $x $y ; do\r\n dir = $HOME\/moz\/ws$i\/js\/src\/optg\r\n cd $dir || exit 1\r\n make --quiet || exit 1\r\n cd ~\/moz\/SunSpider\r\n time valgrind --tool=cachegrind --branch-sim=yes --smc-check=all \\\r\n --cachegrind-out-file=cachegrind.out.optg$i \\\r\n --auto-run-dsymutil=yes \\\r\n $dir\/js `cat ss0-args.txt`\r\n cg_annotate --auto=yes cachegrind.out.optg$i > ann-optg$i\r\n done\r\n fi\r\n}<\/pre>\nss0-args.txt contains this text:<\/p>\n
-j -f tmp\/sunspider-test-prefix.js -f resources\/sunspider-standalone-driver.js<\/pre>\nWhat this does is run just the main SunSpider program, once, avoiding all the start-up processes and all that.\u00a0 This is important for Cachegrind — it means that I can safely use –cachegrind-out-file to name a specific file, which is not safe if running Cachegrind on a program involving multiple processes.\u00a0\u00a0 (I think this is slightly dangerous… if you run ‘sunspider –ubench’ it seems to change one of the above .js files and you have to rerun SunSpider normally to get them back to normal.)\u00a0 I use –branch-sim=yes because I often find it to be useful; at least twice recently it has helped me identify performance problems.<\/p>\n
If I want to focus on a particular Cachegrind statistic, e.g. D2mr (level 2 data read misses) or Bim (indirect branch mispredictions) then I rerun cg_annotate like this:<\/p>\n
cg_annotate --auto=yes --show=I2mr --sort=I2mr cachegrind.out.optgN > ann-optgN-I2mr<\/pre>\nProfiling ‘js’ with Shark<\/h3>\n
To profile ‘js’ with Shark, I use SunSpider’s –shark20 and –test options.\u00a0 I don’t have this automated yet, I probably should.<\/p>\n
Managing Changes with Mercurial<\/h3>\n
Most of my changes are not that large, so I leave them uncommitted in a workspace.\u00a0 This is primitive, but has one really nice feature:\u00a0 when pulling and updating, hg merges the changes and marks conflicts in the nice “<<<” “>>>” way.<\/p>\n
In comparison, with Mercurial queues (which I tried for a while) you have to pop your patches, update, then push them, and it uses ‘patch’ to do the merging.\u00a0 And I hate ‘patch’ because conflicted areas tend to be larger, and because they go in a separate reject file rather than being inserted inline.<\/p>\n
I also avoid doing local commits unless I’m working on something really large just because the subsequent merging is difficult (at least, I think it’s difficult;\u00a0 my Mercurial knowledge still isn’t great).\u00a0 In that case I do local commits until the change is finished, then apply the patch (using ‘hg diff’ and ‘patch’) in a single hit to a newly cloned tree — given Mozilla’s use of Bugzilla, the change will have to be a single patch anyway so this aggregation step has to happen at some point.<\/p>\n
Pre-push Checklist<\/h3>\n
Before landing any patch, I do my best to work through the following check-list.\u00a0 I created this list recently after having to back out several commits due to missing one of the above steps;\u00a0 I give examples of breakage I’ve caused in square brackets.<\/p>\n
It’s quite a list, and I don’t usually do anything with a browser build, when I probably should, so that would make it even longer.\u00a0 And there are other things to get wrong… for example, I never test the –disable-jit configuration and I broke it once.<\/p>\n
When I’m ready to push a change, I make sure my workspaces are up-to-date with respect to the Mozilla repo.\u00a0 I then commit the change to my modified repo, then push it from there into ~\/moz\/ws0\/, then check ‘hg outgoing -p’ on that repo to make sure it looks ok, and then push to the Mozilla repo from there.\u00a0 I try to do this quickly so that no-one else lands something in the meantime;\u00a0 this has only happened to me once and I tried to use ‘hg rollback’ to undo my local changes which I think should have worked but seemingly didn’t.<\/p>\n
After committing, I do these steps:<\/p>\n
That’s a lot of stuff.\u00a0 Two of my more notable conclusions are:<\/p>\n
If you made it this far, congratulations!\u00a0 That was pretty dry, especially if you’re not a Tracemonkey developer.\u00a0 I’d love to hear suggestions for improving what I’m doing.<\/p>\n","protected":false},"excerpt":{"rendered":"
After six months of working on Tracemonkey, I’ve built up a particular workflow — how I use Mercurial, arrange my workspaces, run tests, and commit code.\u00a0 I thought it would be worth describing this in case it helps other developers improve their workflow, or perhaps so they can give me ideas on how to improve […]<\/p>\n","protected":false},"author":139,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[289,467,649],"tags":[],"_links":{"self":[{"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/posts\/146"}],"collection":[{"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/users\/139"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/comments?post=146"}],"version-history":[{"count":0,"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/posts\/146\/revisions"}],"wp:attachment":[{"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/media?parent=146"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/categories?post=146"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/tags?post=146"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}