Infrequently Noted

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!