Visual Studio 2008 & profiling problems

The project I am currently working on is an open sourced project that was originally written for speed, at the cost of clarity and maintainability. While the changes the community have made to clean it up have served that purpose, they have also increased the time it takes to start the game from almost nothing to around four minutes.

When testing every change means sitting through this delay before the results can be seen, development becomes overly time consuming. In order to address this problem, I decided to profile starting up the game. I have Visual Studio 2008 Professional installed, and unfortunately it does not come with a profiler. If you want to profile with Visual Studio 2008, you need to go with its more extensive (and expensive) Team System variant. But there are references to installing standalone extras which in theory allow command line profiling with the less extensive variants.

The first step was downloading and installing the standalone profiler from MSDN. With this installed and a DOS window open, changing the current directory to that of the executable to be profiled. Then adding the profiling tools into the PATH environment variable, so that they could be used locally.

set path=%path%;C:\Program Files (x86)\Microsoft Visual Studio 9.0\Team Tools\Performance Tools


Instrumenting

Profiling the executable requires that it be instrumented.

>vsinstr _SoulFu_.exe
Microsoft (R) VSInstr Post-Link Instrumentation 9.0.30729 x86
Copyright (C) Microsoft Corp. All rights reserved.

Error VSP1011 : Unable to obtain debug information. Link with
the /Profile linker switch.

The executable that is to be profiled needs to have been linked with the /profile switch, which can be done with a simple recompile after changing the corresponding configuration option.



But now Visual Studio fails to compile the solution, with the message LNK2033: bad dll or entry point shown for several failing projects. Googling for this indicates that link.exe and msobj80.dll need to have the same version. It turns out that msobj80.dll which is located in C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE, has been clobbered by an older version during the installation of the performance tools. After more googling, I located a barely comprehensible post by an English as a second language poster, who suggested replacing it with the version in C:\Program Files\Common Files\microsoft shared\VSA\9.0\VsaEnv. Then as this Intel article indicates, killing the mspdbsrv.exe process with the task manager. After this experience, I could now recompile the solution with the required profiling switch.

Trying the instrumentation again..

>vsinstr _SoulFu_.exe
Microsoft (R) VSInstr Post-Link Instrumentation 9.0.30729 x86
Copyright (C) Microsoft Corp. All rights reserved.

File to Process:
   _SoulFu_.exe --> _SoulFu_.exe
Original file backed up to _SoulFu_.exe.orig

Successfully instrumented file _SoulFu_.exe

Profiling

The process goes along these lines, the profiler is first started, then the instrumented executable is run and exercised in the ways that would benefit from profiling, then the profiler is stopped and the resulting profiling information is processed.

Starting the profiler..

>vsperfcmd /start:trace /output:soulfu.vsp

Microsoft (R) VSPerf Command Version 9.0.30729 x86
Copyright (C) Microsoft Corp. All rights reserved.

Running the instrumented executable..

>_SoulFu_.exe

Stopping the profiler..

>vsperfcmd /shutdown
Microsoft (R) VSPerf Command Version 9.0.30729 x86
Copyright (C) Microsoft Corp. All rights reserved.


Shutting down the Profile Monitor
------------------------------------------------------------

Processing the profiling data..

>vsperfreport soulfu.vsp /summary:all

Microsoft (R) VSPerf Report Generator, Version 9.0.0.0
Copyright (C) Microsoft Corporation. All rights reserved.

File opened
Successfully opened the file.
A report file, soulfu_Header.csv, has been generated.
A report file, soulfu_MarksSummary.csv, has been generated.
A report file, soulfu_ProcessSummary.csv, has been generated.
A report file, soulfu_ThreadSummary.csv, has been generated.
...

With the .vsp and .csv files in the same directory, PerfConsole can now be run. At its internal prompt, load soulfu.vsp gets it to load in the profiling information. However, the information it displayed was confused with the external and internal time percentages being large numbers rather than actual percentages. It also was unable to determine whether the data was intrument or sample, so defaulted to sample mode. This meant I was unable to see the call tree and other useful information, presuming that information would have been displayed correctly.

A little more searching indicated that I needed to set environment variables to indicate whether the instrumentation data was what classified as sampled or instrumented. I decided to try again, but profiling with explicit instrumentation, rather than sampling.

>VsPerfCLREnv /traceon
Enabling VSPerf Trace Profiling of managed applications
(excluding allocation profiling).

Current Profiling Environment variables are:
COR_ENABLE_PROFILING=1
COR_PROFILER={6468ec6c-94bd-40d3-bd93-4414565dafbf}
COR_LINE_PROFILING=0
COR_GC_PROFILING=0

Rerunning the profiler, the instrumented executable and then stopping the profiler gave me a new .vsp file for processing.

So I started the processing step again and waited..

>vsperfreport soulfu.vsp /summary:all

Microsoft (R) VSPerf Report Generator, Version 9.0.0.0
Copyright (C) Microsoft Corporation. All rights reserved.

File opened
Successfully opened the file.
A report file, soulfu_Header.csv, has been generated.
A report file, soulfu_MarksSummary.csv, has been generated.
A report file, soulfu_ProcessSummary.csv, has been generated.
A report file, soulfu_ThreadSummary.csv, has been generated.

I waited and waited. I left it going overnight, for over nine hours. It sat at around 50% usage of the CPU core it was running on for this entire time.


Next steps

At this point I gave up. Between the corrupt information shown by PerfConsole and the inability to generate .csv files for explicitly instrumentated profiling data I have wasted enough time on this. My next step is to just download Visual Studio 2010 Ultimate from MSDN and use that. I am going to have to waste more time rebuilding dependencies, but on the other hand I will get visual profiling tools and hopefully it will just work.