Profiling a dll plugin

Question

I want to profile a dll plugin in C++. I have access to the source (being the author/mantainer) and can modify them (if needed for instrumentation). What I don't have is the source/symbols/etc of the host program which is calling the dll. I only have the headers needed to build the plugin. The dll is invoked upon action from the client.

What is the best way to proceed for profiling the code? It is not realistic to "wrap" an executable around the dll and it would be not useful because since in the plugin I am calling some functions from the host AND i need to profile those paths, a wrapper would skew the performance.

EDIT after Kieren Johnston's comment: Ideally I would like to hook into the loaded dll just like the debugger is able to (attaching to the running host process and placing a breakpoint somewhere in the dll as needed). Is it possible? If not, I will need to ask another question to ask why :-)

I am using the TFS edition of Visual Studio 2010.

Bonus points for providing suggestions/answers for the same task under AIX (ah, the joys of multiple environments!).

Answer 1

This is possible albeit a little annoying.

1. Deploy your plug-in DLL to where the host application needs it to be
2. Launch your host application and verify that it is using your plug-in
3. Create a new Performance Session
4. Add the host EXE as a target in the Session from step 3
5. Select Sampling or Instrumentation for your Session
6. Launch the profiling session

During all this keep your plug-in solution loaded and VS should find the symbols for your plug-in automatically.

Answer 2

Not sure about VS10, but in older ones, you debug the dll by specifying the exe for running it.

Let's split the problem into two parts: 1) locating what you might call "bottlenecks", and 2) measuring the overall speedup you get by fixing each one.

(2) is easy, right? All you need is an outer timer.

That leaves (1). If you're like most people, you think that finding the "bottlenecks" cannot be done without some kind of precision timing of the parts of the program. Not so, because most of the time the things you need to fix to get the most speedup are not things you can detect that way. They are not necessarily bad algorithms, or slow functions, or hotspots. They are distributed things being done by perfectly innocent-looking well-designed code, that just happen to present huge speedup opportunity if coded in a different way.

Here's an example where a reasonably well written program had its execution time reduced from 48 seconds to 20, 17, 13, 10, 7, 4, 2.1, and finally 1.1, over 8 iterations.** That's a compound speedup factor of over 40x. The speedup factor you can get is different in every different program - some can get less, some can get more, depending on how close they are to optimal in the first place. There's no mystery of how to do this. The method was random pausing. (It's an alternative to using a profiler. Profilers measure various things, and give you various clues that may or may not be helpful, but they don't reliably tell you what the problem is.)

** The speedup factors achieved, per iteration, were 2.38, 1.18, 1.31, 1.30, 1.43, 1.75, 1.90, 1.91. Another way to put it is the percent time reduced in each iteration: 58%, 15%, 24%, 23%, 30%, 43%, 48%, 48%. I get a hard time from profiler fans because the method is so manual, but they never talk about the speedup results. (Maybe that will change.)