Module Of Interest Never Appears in VTune Results

shortsword · ‎10-19-2005

I am attempting to tune an application that consists of one small Windows executable and several large dlls that implement various portions of the application functionality.

I am particularly interested in three of the dlls of this application. When the application executes dll A is ALWAYS exercised. dll B is called when particular new functionality is executed. dll B in turns calls dll C which was built by a third party.

When I run the application using VTune and have it exercise this new functionality, dll A is never listed in the module view as one of the modules sampled. Both dll B and dll C are listed in the module view but when you drill down into either dll B and dll C they both list function names that should appear ONLY in dll C. Since dll B is the newmodule that has been recently added to the application, it is the one that I would like to tune if the VTune data would lead in that direction. But, I don't seem to be actually getting any data from that module.

I know that dll B is being exercised, and exercised quite heavily when I run the test because the application cannot possible run the test I am running and give me the output that the test gives without exercising the functionality in that dll to a very large extent.

The application is built using MS C and C++ compilers that come with MS Visual Studio 6.0.The application is not built using Visual Studio projects. Rather, it is built using a ratherlarge set ofgnumake files.

Each dll in the application has an associated MS pdb file present in the same directory in which the dll resides. This is the application's bin directory. Some of the dlls reside in subdirectories of the bin directory and their pdb files are also in the same subdirectory. The bin directory is different from the build directory but only by the root directory in which the build is done and the in which the application is installed. The build directory is also available at VTune run time and VTune has been set to see the build bin directory and recursive subdirectoriesas one of the symbol directories. Also, the source directory and its recursive subdirectories in the build directoryare set as one of the source directories in VTune.

Does anyone know of any circumstances under which VTune might act as I have described? And if so, what might I need to do to get VTune to give me data in the dll that is not currently being included.

Thank you for any insight or help that you might be able to give me.

David_A_Intel1 · ‎10-20-2005

Hi shortsword:

I will have to ask you some questions so that I can better understand the execution nature of your application.

For example, how long does the application run? Of that time, how much of it is actually code in dll A? If dll A is simply loading dll B and calling into it, you may never see any samples in dll A. Sampling gives you a statistical representation of where theprocessor is spending its time.

Are you configuring the VTune analyzer to "launch" your application? I assume you are collecting Clockticks and Instructions Retired?

If you want to get an accurate picture of the calling relationships, you can use call graph (available in the Wizards list).

Regards,

shortsword · ‎10-20-2005

DaveA,

dll A is the real heart of the application. In fact, the exe file really has only one job, parse the application arguments, put them into a structure that is easily interpreted and then load and initialize dll A passing the structure to it. From there dll A takes over as the actual application that is running.

dll B is only one of many dlls that dll A might call during an application run. However, ecause of the nature of the test I am giving it, dll A must call various functions in dll B many thousands of times during the test run. In fact, the fact that the modules that are identified by VTune as dll B and dll C are listing out the particular functions that they are (all of which actually reside in dll C), tells me that the code in dll B is being exercised.

The test lasts for 800 seconds (13.3 minutes). Yes, I have VTune starting the application and I have VTune delaying the beginning of sampling for 300 seconds (5 minutes) due to the long ramp-up that the application test takes before it really settles into the processing intensive steady state where I expect dll A to be calling dll B on a regular and often basis.

I have VTune collecting clockticks, instructions retired, and instructions retired / clockticks (CPI). I am also sampling several system wide parameters such as threads, Processor time, processor queue length, context switches, and several others. (I tried to go over to the test machine and get the full list of sample items for you. The machine is being used for other performance testing at the moment and they have me locked out. If you need that list, I can get it later today.

Does any of this information help?

David_A_Intel1 · ‎10-20-2005

Sorry for maybe appearing dense, but if dll A is only calling into dll B, then you may still not see any samples in dll A. I mean, dll A must be doing something CPU-intensive to show up in the results.

The other thought is, are you starting from the Process view? Press the Process button at the top of the Sampling view and then select your process from the list of processes running on the system. Next, press the Modules button (or Threads if you want to limit which threads you look at) and see if dll A shows up.

Finally, (sorry if you already said this) are you building dll A with full debug information? It should still be the "Release" build, but you should include debug info.

Regards,

shortsword · ‎10-21-2005

DavaA,

dll A is calling dll B a lot. It is also calling several other dlls , and it is doing a lot of its own processing as well.

I do not have a good idea of the proportion of time spent in each of these.

That's one of the reasons for running VTune.

David_A_Intel1 · ‎10-24-2005

Hi shortsword:

Try opening the DLL in the Static Module Viewer:

1. Select the Open Static Module Viewer from the File menu.
2. Review the module and function list to ensure that the expected routines are present with the Functions with source information check box checked. If modules or functions are missing, ensure you have created a binary with debug information.

Regards,