From the “hard drive killer” department…

I was pretty excited to see that VS2005 has an embedded profiler – Micro$oft had to come up with a new name of course – “performance analyzer”. I threw HangTheDJ at it, going with all the defaults, and was served up with this gem before HangTheDJ even finished loading (as I happened to only have 8GB free at the time):

Performance automation returned the following error: : Error VSP1369 : Out of disk space: this scenario requires roughly 63073172 KB of disk space.

Yes, that says 63GB. Oh, to have the box of a Micro$oft developer…

And after running it on a box with more space, I get a 45GB “vsp” file, which when I try to open in Visual Studio, generates this:

Error VSP1748 : VSP file is too large for analysis

So, I followed the hint given along the way, namely “You may want to try analyzing it using vsperfreport.exe.” OK. I figured out where that tool was located (…Program Files\Microsoft Visual Studio 8\Team Tools\Performance Tools) and tried that approach:

Error VSP1748 : VSP file is too large for analysis

Fool me once… oh well, sigh. What fun. I did manage to get a little information out of the partial file created when it ran out of disk space. My HangTheDJ progress bar was redrawing itself every time I updated the “position” of the progress. I updated the code to only redraw when the pixel math indicated that there would be an actual change to the display. Cool.

I guess the only reasonable step left with this thing is to figure out the options to only instrument targeted areas of the code. What a shame. To be continued…

OK, after a little reading (doh), it sounds like I should…

  • always use a release build (but with debug symbols added, of course)
  • start with sampling
  • proceed with instrumented profiling only after finding problem areas with sampling

So I cloned the Release config, naming it Profiler. I had to change all the targets to use the “Profiler” subdirectory (doh). Then I added profiling and debugging information to the code generation and linker sections of the configuration. Rebuild all, start a “sampling” profiler run.

It’s showing that my database reads are taking the biggest hit, which makes sense. Sounds like time to revisit that Jet-to-sqlite replacement…

Leave a Reply