{"id":200,"date":"2013-08-02T12:15:28","date_gmt":"2013-08-02T16:15:28","guid":{"rendered":"http:\/\/blog.mozilla.org\/nfroyd\/?p=200"},"modified":"2013-08-02T12:15:28","modified_gmt":"2013-08-02T16:15:28","slug":"i-got-99-problems-and-compilation-time-is-one-of-them","status":"publish","type":"post","link":"https:\/\/blog.mozilla.org\/nfroyd\/2013\/08\/02\/i-got-99-problems-and-compilation-time-is-one-of-them\/","title":{"rendered":"I got 99 problems…and compilation time is one of them"},"content":{"rendered":"

Over the past week or so, there have been a few conversations on #developers<\/tt> about the ever-increasing time it takes to compile Firefox.\u00a0 Compiling Firefox used to be a relatively quick affair<\/a> (well, on my machine, at least) and I’ve grown dissatisfied recently with builds taking ever-longer.\u00a0 All of the aforementioned discussions have boiled down to “well, we’re adding a lot of code and all that code takes longer to compile.”<\/p>\n

Surely that can’t be the whole story.\u00a0 A mozilla-central build from a day or two took about 24 minutes on my machine (Linux x86-64 hyperthreaded 8-core @ 2.6GHz, srcdir on SSD, objdir on mechanical hard drive).\u00a0 We are not compiling 2.4x times more code than we were a year ago…or are we?\u00a0 Let’s look at some numbers.<\/p>\n

I looked at my mozilla-central repository for some convenient tags to pick from and found the FIREFOX_AURORA_${REV}_BASE<\/tt> set of tags.\u00a0 I started compiling with mozilla-central tip, and then with FIREFOX_AURORA_24_BASE<\/tt>, and resolved to go as far back as I could without undue fiddling with things that wouldn’t compile.\u00a0 I made it to FIREFOX_AURORA_14_BASE<\/tt> before hitting compilation errors with moz_free.\u00a0 (19 and previous required small fiddling with js\/src<\/tt> to set the right PYTHON<\/tt>, but that was easily scriptable.)\u00a0 That gives me 11 markers covering over a year of development.<\/p>\n

I didn’t try compiling things multiple times to see how much the numbers fluctuated.\u00a0 I didn’t attempt to control for operating system disk caches or anything like that, just hg up -r $TAG<\/tt>, generated configure, ran configure --enable-optimize --disable-debug --disable-gstreamer<\/tt> (I haven’t bothered to get my gstreamer dependencies right on my development box) in a newly-created objdir, and recorded time for make -srj20<\/tt>.\u00a0 The compiler was GCC 4.7 from Debian stable.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
m-c tag<\/td>\nreal<\/td>\nuser<\/td>\nsys<\/td>\n<\/tr>\n
15<\/td>\n13m2.025s<\/td>\n83m36.229s<\/td>\n5m51.238s<\/td>\n<\/tr>\n
16<\/td>\n13m40.359s<\/td>\n87m56.302s<\/td>\n6m15.435s<\/td>\n<\/tr>\n
17<\/td>\n12m58.448s<\/td>\n94m21.514s<\/td>\n6m35.121s<\/td>\n<\/tr>\n
18<\/td>\n14m21.257s<\/td>\n112m42.839s<\/td>\n7m36.213s<\/td>\n<\/tr>\n
19<\/td>\n15m8.415s<\/td>\n120m48.789s<\/td>\n8m8.151s<\/td>\n<\/tr>\n
20<\/td>\n16m26.337s<\/td>\n137m34.680s<\/td>\n9m11.878s<\/td>\n<\/tr>\n
21<\/td>\n18m55.455s<\/td>\n165m29.433s<\/td>\n10m45.208s<\/td>\n<\/tr>\n
22<\/td>\n19m27.887s<\/td>\n185m3.242s<\/td>\n11m53.853s<\/td>\n<\/tr>\n
23<\/td>\n21m9.002s<\/td>\n203m46.708s<\/td>\n12m51.740s<\/td>\n<\/tr>\n
24<\/td>\n21m51.242s<\/td>\n206m49.012s<\/td>\n12m55.356s<\/td>\n<\/tr>\n
tip<\/td>\n24m37.489s<\/td>\n219m27.903s<\/td>\n13m47.080s<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Those 10-minute clobber build times were apparently the result of warm disk cache or my dreams. Or perhaps they’re due to an older compiler; I only started using GCC 4.7 recently and I’ve done some tests that show it’s a fair amount slower than GCC 4.4. Or maybe I was using a different build config then. Whatever the reason, we can see that compilation times have been increasing steadily, but can we correlate that to anything?<\/p>\n

Let’s look at the number of C++, C, WebIDL, and IPDL source files. We include the last two because the conversion to WebIDL has been cited as a reason for increasing compilation times and IPDL because the IPDL compiler generates a number of source files as well (roughly three source files for every IPDL file). The C++ source files are split by extension; .cpp<\/tt> is the usual prefix to use inside Gecko, so separating .cpp<\/tt> and .cc<\/tt> gives some idea of how much outside C++ source code is being compiled. (Just counting source files is subject to issues, since we don’t compile everything in widget\/<\/tt><\/a> for every platform, but we’re counting all the source files therein as if they were. This is a rough estimate.)<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
m-c tag<\/td>\ncpp<\/td>\ncc<\/td>\nc<\/td>\nwebidl<\/td>\nipdl<\/td>\n<\/tr>\n
15<\/td>\n4060<\/td>\n577<\/td>\n2503<\/td>\n32<\/td>\n206<\/td>\n<\/tr>\n
16<\/td>\n4117<\/td>\n1273<\/td>\n2893<\/td>\n34<\/td>\n213<\/td>\n<\/tr>\n
17<\/td>\n4173<\/td>\n1278<\/td>\n2895<\/td>\n38<\/td>\n221<\/td>\n<\/tr>\n
18<\/td>\n4468<\/td>\n1405<\/td>\n3123<\/td>\n61<\/td>\n227<\/td>\n<\/tr>\n
19<\/td>\n4498<\/td>\n1408<\/td>\n3118<\/td>\n78<\/td>\n228<\/td>\n<\/tr>\n
20<\/td>\n4586<\/td>\n1418<\/td>\n2779<\/td>\n169<\/td>\n228<\/td>\n<\/tr>\n
21<\/td>\n4605<\/td>\n1392<\/td>\n2831<\/td>\n231<\/td>\n228<\/td>\n<\/tr>\n
22<\/td>\n4979<\/td>\n1392<\/td>\n2980<\/td>\n305<\/td>\n228<\/td>\n<\/tr>\n
23<\/td>\n5072<\/td>\n1393<\/td>\n2982<\/td>\n344<\/td>\n231<\/td>\n<\/tr>\n
24<\/td>\n5101<\/td>\n1330<\/td>\n2983<\/td>\n413<\/td>\n234<\/td>\n<\/tr>\n
tip<\/td>\n5211<\/td>\n1427<\/td>\n3029<\/td>\n436<\/td>\n234<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

First things first: we have a lot of code in the tree.<\/p>\n

Now, there’s a couple of interesting things to point out. While there’s a lot of IPDL source files, the increase in IPDL can hardly be held responsible for the increase in compile time. So that’s one suspect out of the way. From 16 to 17, we barely increased the amount of code, but build times went down<\/strong>. This change might point to the recorded times being subject to quite a bit of variability.<\/p>\n

We added a lot of WebIDL files from 20 to 21 while holding everything else constant and build times went up quite a bit! But we added roughly the same number of WebIDL files from 21 to 22 along with a lot<\/strong> more code and while build times went up, they didn’t go up by the same amount: 28 minutes of user time going from 20 to 21 and ~20 minutes of user time going from 21 to 22. There are a number of reasons why this could be so: we might not be compiling all those 500 C\/C++ source files we added in 22 (ICU landed off by default in 22, so that’s ~400 files right there), the WebIDL files added in 21 might have had more of an impact, compilation-wise, the timings might fluctuate quite a bit, and so on and so forth. And notice that we added the same number of WebIDL files again from 23 to 24 and build times hardly changed<\/strong>. Sure, WebIDL means more files to compile. But I don’t think they are adding a disproportionate amount of time.<\/p>\n

And finally, source code file counts. We had about 7800 source code files to compile back at Aurora 15 (remember, IPDL counts as three). We have about 10600 source files to compile now on trunk. That’s about a 40% increase that corresponds to roughly a doubling in time to compile. And yes, there’s also a lot of JS and other things that have been added that increase our time to compile. But I don’t think the amount of source code is the whole story.<\/p>\n","protected":false},"excerpt":{"rendered":"

Over the past week or so, there have been a few conversations on #developers about the ever-increasing time it takes to compile Firefox.\u00a0 Compiling Firefox used to be a relatively quick affair (well, on my machine, at least) and I’ve grown dissatisfied recently with builds taking ever-longer.\u00a0 All of the aforementioned discussions have boiled down […]<\/p>\n","protected":false},"author":320,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"_links":{"self":[{"href":"https:\/\/blog.mozilla.org\/nfroyd\/wp-json\/wp\/v2\/posts\/200"}],"collection":[{"href":"https:\/\/blog.mozilla.org\/nfroyd\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.mozilla.org\/nfroyd\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.mozilla.org\/nfroyd\/wp-json\/wp\/v2\/users\/320"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.mozilla.org\/nfroyd\/wp-json\/wp\/v2\/comments?post=200"}],"version-history":[{"count":0,"href":"https:\/\/blog.mozilla.org\/nfroyd\/wp-json\/wp\/v2\/posts\/200\/revisions"}],"wp:attachment":[{"href":"https:\/\/blog.mozilla.org\/nfroyd\/wp-json\/wp\/v2\/media?parent=200"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.mozilla.org\/nfroyd\/wp-json\/wp\/v2\/categories?post=200"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.mozilla.org\/nfroyd\/wp-json\/wp\/v2\/tags?post=200"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}