Thursday, January 13, 2011

Visual C++ 2010: IDE Memory & Performance Problems. Consider Precompiled Headers

If all you need is just the PCH solution you can scroll down to “The PCH Solution” section immediately. Otherwise you may want to read about how I came to this solution and hopefully find some clue for solving your own problem.

Well, when I first installed Visual C++ 2010 I was full of anticipation and excitement about new IDE’s features. Certainly, with its IntelliSense technology Microsoft had gone far ahead of all its rivals. Visual Studio’s brand-new on-the-fly compilation and real-time error reporting capabilities drastically speed up coding and make the whole development process much easier.

Quite a bit of time has passed since then. I enjoyed the new extremely convenient IDE and kept on praising Microsoft for this incredible invention. But one day things began to get worse.

I noticed some strange IDE’s behavior. After a few minutes of editing the code the IDE was getting almost irresponsible, the window was failing to redraw fast and intensive HDD I/O was occurring. Something was happening and until it ends it was practically impossible to work. This effect started to appear more and more often. In some editing sessions I was getting it every 20 to 40 new lines of code.

I can’t point out exactly when it began. Maybe when I added a couple of headers containing some tricky macros. Or maybe when the line count in my entire solution exceeded some critical value.

All I knew it was about IntelliSense. Simply turning it off was not an option as without it the whole IDE would have lost all its appeal. No-o-o... I desperately needed IntelliSense, but a working IntelliSense!

My first step was using Google (sounds weird, huh? )) Soon I found that world falls into the following two parts. The first one is the people who are completely satisfied with new Visual Studio 2010 and have not even a single performance problem with it or a problem that can be solved relatively easily. The other world’s part is a bit unluckier and suffers from performance problems which seem mystical as Microsoft can’t do anything with them. Except referring people to absolutely useless solution checklists.

I read many blog posts, advices and other info and nothing helped. However I think some of those are worth looking at:

http://support.microsoft.com/kb/981741/en-us

http://weblogs.asp.net/scottgu/archive/2007/11/01/tip-trick-hard-drive-speed-and-visual-studio-performance.aspx

Then I started monitoring CPU and memory usage via Process Explorer. It showed that the moments of performance drop relate to high physical memory usage followed by the massive flush to the page file. When I was typing the lines of code memory usage was growing gradually until the memory was totally flooded and Windows had no other way but to flush it to the page file. This explains intensive hard disk I/O which hindered the whole system’s performance. While all this was happening no CPU was being consumed at all. At the same time no particular process in Process Explorer was looking as a memory hog (although multitudes of vcpkgsrv.exe and msbuild.exe processes were spawning and dying all them looked pretty decent). Probably memory was being allocated internally by some system processes, I don’t know.

I must say I have Windows XP SP3 on my development machine. I searched for any information which could regard specifically to XP problems but found none. The next idea was to increase my RAM size. I had only 2GB and since I already did consider a memory upgrade just before these VS2010 problems it took me not long to decide. With 4GB of RAM things became better but not much. It still was hogging all the 4 gigs to the end and then flushing. Only these “hog-flush” loops got longer allowing me to type a bit more code.

Then I tried things such as:
  • Turning off/on and tweaking various options in the Tools\Options\Text Editor\C/C++\Advanced section. Didn’t help...
  • Turning on Diagnostic Logging (located also in the above mentioned section) with various verbosity levels and trying to look for any errors. Grrrrr, errors were found but too cryptic to give me a clue...
  • Rearranging code in files and recreating project/solution files. No luck...
  • Refactoring my most tricky macros. Nothing...
  • Installed Visual Studio 2010 Service Pack 1 Beta. Didn’t help
The PCH Solution

I kept trying and finally found the solution! This is it:

http://blogs.msdn.com/b/vcblog/archive/2010/01/26/precompiled-header-files-in-visual-studio-2010.aspx

Although it doesn’t contain a direct indication to my memory problem, these two phrases made me to start exploring:
“The intellisense compiler can load these iPCH files to save not only parse time, but memory as well: all translation units that share a common PCH will share the memory for the loaded PCH, further reducing the working set.”
“iPCH and build compiler PCH share the same configuration settings (configurable on a per-project or per-file basis through  “Configuration Properties->C/C++->Precompiled Headers”).”
The fact is when I started my project I took decision not to use precompiled headers at all. First, because at that time it was of course a very small project. Second, I thought I’d better have more flexibility as to header inclusion and therefore every translation unit would only have a minimal set of headers required for the compilation.

But time has passed and now the project had grown to a moderate size of ~40K lines of code and uses STL and 7 other 3rd party libraries some of which are quite big.

It took me about an hour to study the details and set up the whole PCH thing which involved rearranging includes in every file and changing the project settings. The following info helped me much and I suggest reading it thoroughly:

http://www.cygnus-software.com/papers/precompiledheaders.html

http://msdn.microsoft.com/en-us/library/z0atkd6c.aspx

And this is what I’ve got now:
  • No memory flooding problems
  • IntelliSense is working smo-o-o-thly
  • Compilation became blazingly fast
  • Piece of mind
Wish your VS2010 problems got solved!

No comments: