The Tragedy
Recently I was looking into doing more dev on a Windows machine — you know, because basically all our users on are on Windows — and ran into the sad, sad fact that a clean build is going to take me 40 minutes on a brand new “pro-level” laptop. That’s just unacceptable. I filed a bug for that, the response was roughly “yeah we know, get a better machine” and was closed as invalid. I guess I get it, as far as a short term solution that makes sense, but this is pretty sad. It’s sad because on my 3 year old MacBook Pro I get 22 minute clean build for OSX. On my Linux desktop with similar specs I’m seeing 18 minute builds (this is without ccache).
System specs:
– Win10 laptop, Intel Xeon E3-1505 M @ 2.80GHz, 32 GB RAM, SSD
– OSX 10.12.1 laptop, Intel Core i7-4960HQ @ 2.6G0Hz, 16 GB RAM, SSD
– Ubuntu 16.04 desktop, Intel Core i7-4770 CPU @ 3.40GHz, 32 GB RAM, SSD
I should note we’re talking about clobber builds here for a platform dev poking around in C++. A lot of work has been done to make builds for frontend folks super fast with artifact builds (we’re talking a minute or two). We could also look at iterative builds, but often I’m working in heavily shared files that it doesn’t really matter (strings etc).
Not all is lost
It sounds like there’s some work to make it better although I don’t have any bug numbers, and have no clue what the priority is. It was also pointed out that sccache is going to work locally on Windows which should be a big improvement, it will be interesting to see some actual numbers.
I’m not sure if there’s more I can do to improve things as-is, here’s what I’ve done so far:
– Disabled malware scanning for my dev directory
– Configured the laptop to “performance” mode
Just piping the build output to /dev/null was actually rather effective, it shaved about 5 minutes from the build time. This isn’t a great solution though as I’d like to see progress and warnings. Another suggestion was to disable parts of Firefox that I don’t need, unfortunately I often tinker with files that are used throughout the codebase so I can’t disable things without worrying about breaking them.
Any other suggestions out there? Links to bugs?
The 5 minute saving for no console output is pretty extraordinary. How much output is there? That definitely seems like an avenue worth investigating.
I agree! Filed bug 1326353 for further investigation. I’m not sure what the volume is, but I guess it has something to do with mozmake/sh.ex/windows command line.
What gets me most is this is an anecdotal workaround that’s I’ve heard about for years.
Now that we have clang-cl builds stood up, cross compiling for Windows from Linux is becoming more practical. Cross compiling should let us have comparable times to Linux builds.
That seems like it could work well for build infrastructure, but how would you envision it working locally? Maybe an NFS mount to my remote linux machine and a putty session? It would be kind of cool of icecc tied in so I wouldn’t have to think about it.
The latest versions of visual studio have much improved link times. But really, most of this is down to poor performance of various parts of Windows and there is not a lot to be done about that beyond throwing hardware at the problem.
IIRC, much of Firefox’s Windows build woes stem from Mozilla’s insistence on supporting old Windows versions, e.g. XP, nearly no one uses and which even Microsoft no longer support. Unsurprisingly, the Windows builds have suffered.
I’m not sure how supporting XP hurts local build times, but you’ll be happy to hear we’re removing support for XP and Vista.
Like Eric, I’d be really interested in any citations for that claim. If there were to be any impacts from maintaining legacy support for a 15yo platform, I’d expect it to be at runtime from having to use legacy versions of core libraries to get an executable that runs on all versions of Windows.
I’d love to hear why that is the case.