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