Profiling a DLL with Visual Studio 2005

I'm working on an audio application which can use 3rd party DLLs (plugins) from other manufacturers. These DLLs typically offer algorithms to provide audio processing effects such as EQ and reverb.

I know from past experience that it's quite common for plugin DLLs to be processor hungry. Often I'll see a jump of around 20% cpu usage, just when using one plugin DLL. However, one particular manufacturer's plugin was consistently maxing out both cores of my Core2 Duo, running at 2.26GHz! I'm currently working with them to resolve this. Their code and mine is all built with VS2005 and they've already managed to identify some bottlenecks in their code. Through this, we've gotten the cpu usage down from 100% to around 66% on both cores. However, when I run the same software with the same settings on a Mac (built using gcc) cpu usage is much better (only around 46% when performing the same tasks). So we've been considering the possibility of profiling the plugin DLL.

Does anyone here have any advice about profiling an app? I've read something about Profile Guided Optimization. It seems as if you make a special build which you run and use normally - and that somehow generates some profile information which you can feed back into the build process so that the next build will perform better. Sounds really neat if it works! Anyone ever used it?

[Edit...] Or alternatively, can anyone recommend a good profiling utility?

Google has some. They're not too bad.

Viggy

There is a simple Very Sleepy profiler released under GNU Public License. In contrast to Visual Studio stand-alone profiler, it has some GUI and doesn't require compiling the module with /PROFILE switch. To see the functions and source code, before compilation in Visual Studio "Generate Map File" option should be switched ON and MAP, PDB files should be located in the same directory where module binary is located.

There is a good article related to Profile Guided Optimization that explains what kind of optimization is made in the code.

Regards,
Armen.