Note To Self: Faster Chromium Builds (Updated)

I spend my days in C++ on 32-bit Windows XP in Visual Studio 2005. The build and link times for Chromium are painful on this setup, in part because there has been flakiness with the multi-process build option for VS, in part because the incremental linker which can dramatically speed up builds can run out of memory on some boxes (so is disabled by default), and because Visual Studio steadfastly refuses to give developers any options about how, when, where, and why to rebuild the IntelliSense database. The last one is probably the most intractable. On 64-bit windows, incremental linking is turned on based on the assumption that you’ll have lots of RAM on that shiny 64-bit box. Similarly, Chromium builds using multi-process flags under VS’08 since it’s known to be less flaky there. It seems I run with the “please hurt me more” configuration.

“Distributed builds!”, I hear you scream.

That’s not a bad path. For Mac builds, the office’s ad-hoc distcc cluster is a godsend (particularly given that my Mac is a lowly laptop). For Visual Studio, there’s IncrediBuild, but it has left me wanting a better option. Recently I’ve just thrown caution to the wind and started over-riding the safety valves on /MP and incremental linking via my ~/.gyp/include.gypi file:

  'variables': {
    'msvs_multi_core_compile': 1,
    'msvs_large_module_debug_link_mode': '2'

You can get these settings to take effect without updating your repo by running gclient runhooks --force from the top level directory if your Chromium checkout. VS should then prompt you to reload the project (assuming you’re using the GUI).

Hopefully this recipe will help others. It has dropped small rebuilds on my system from north of 10 minutes to below 2.

Update: So the real answer, apparently, is to get dual quad-core i7’s running Vista 64 under VS 2008. Holy cow, what a world of difference. All hail the Powers That Be for new, awesome hardware!


  1. lloyd hilaiel
    Posted August 22, 2009 at 5:32 am | Permalink

    “The last one is probably the most intractable.”

    Not 100% intractable, there’s a big ass off switch:

    find and rename feacp.dll to disable intellisense. For me, any value provided by that feature is nullified by its piss poor perf.


  2. Posted August 22, 2009 at 3:44 pm | Permalink

    Yeah, I’ve seen instructions on how to disable intellisense, but that’s not what I’m gunning for. If I have to live without vs. having it suck, I’ll have it suck. in a codebase as big as Chrome, it’s an absolute life-saver.

    What I want instead is a way to shut off scanning, schedule it, or make it work from a “read-only” database so that it stops slamming my disk when I’m trying to do other things. I know the VS team protests that intellisense does shut off when other CPU intensive things are going, but it’s not a question of throughput, it’s a question of latency. Intellisense making things laggy for any period of time is pretty much the cardinal sin in my mind.