[boost] [bimap] Excessive Compilation Memory Usage with VC8 - 1.35.0

From: Bryan Petty (etierra_at_[hidden])
Date: 2008-07-07 15:23:17

Hi,

I've run into some serious problems getting my application to build
after adding some usage of boost::bimap. In my application's case, a
single bimap of any type causes the VC8 compiler to use more than 1GB
of extra ram than it does normally (which is around 1GB). It compiles
without errors, and runs flawlessly, but if I add a second bimap of
any type elsewhere in my code, the additional ram usage becomes a
problem and the build fails due to lack of sufficient memory to finish
the compilation. These bimaps are declared and defined in a static
library linked to my application which is setup with pre-compiled
headers for that library. The compilation generally takes the most ram
during compilation of the pre-compiled headers, and that's where this
fails.

This seems especially weird since from what I can tell, bimap is
simply an implementation of boost::multi_index for a specific purpose,
and we already make use of 4 different multi_index containers
throughout our application without any memory consumption issues.

I've taken the time to test this with a new skeleton Win32 project,
and used the simple bimap example included with Boost. Without bimap,
cl.exe only peaks at 3.25MB committed (measured with Process Monitor)
in debug mode, but when I copy in the simple bimap example it peaks at
325MB committed in debug, and 148MB committed in release. I don't see
anywhere near these kind of numbers with GCC on x86 linux, g++ stays
around 3MB.

System: Windows XP, VC8, 2GB RAM, Boost 1.35.0

One user on #boost experienced similar numbers when compiling with VC9 as well.

When I add more bimaps in the simple example, it doesn't add as much
of a jump as the first does, but it's still fairly significant (from
325MB to 360MB in debug with the second bimap).

I have no idea how to go about debugging this.

Regards,
Bryan Petty