Sometimes you get external indicators of project scale. Working on a project you understand well often leaves you with the impression that it's a "typical" project. In one instance, the VC linker begs to differ.
On this project the VC linker regularly runs out of memory. The Task Manager's rollercoaster memory diagram looks more like the flightplan of an ICBM, altitude and all to scale.
You should know that I run my Windows systems that have 2+ Gb of RAM with virtual paging disabled. Like many geeks I have dedicated brain matter for managing the Alt-Tab stack and I flip between dozens of windows without really looking. These neurons expect Alt-Tab to be instantenous (see my Vista Nitpicks below) and paging has ever been the enemy of fast context-switching. (particularly since the NT kernel seems to always want 50% of memory to be paged out - God I wish there was an option to control this)
Now combine a stratospheric linkage course with a pageless system and you'll get "operator new" to throw or malloc to return NULL. It all goes south from here obviously, and the errors you get tend to be quite nonsensical. Basically whatever the application (linker) was doing is declared to have failed, without description of the reason. All fair up to here, I have a part of the blame.
Where it stings: it's really hard for me to know what is causing the linker to consume so much memory and take steps to improve this. I have clues, for sure, but I have no real toolset to apply to bring the situation under control. The linker need not be perfect if I can do work to lessen (or direct) its work. If there's interest I will expand on what I think could help.
BTW saying that I should re-enable paging merely sidesteps the real issue. If I do this the linker will then spill onto disk and link times will increase exponentially. That's just as bad as failing the link in my opinion because it slows down the "change-compile-debug" loop, costing precious productivity.