views:

38

answers:

1

I am profiling an application using VerySleepy 0.7. The application is written in C++ with Qt 4.6.x, compiled with VS 2005 and is running on Windows 7 Ultimate x64.

The highest usage by far is a call to RtlPcToFileHeader

Exclusive Inclusive %Exclusive %Inclusive Module
33.67s    33.67s    15.13%     15.13%     ntdll

It is not clear to me from the documentation what RtlPcToFileHeader is but because it is referenced under "Error Handling Functions" it seems like it is something that should not be there. That being said, since it was used basically throughout my profiling capture, it could also be some very basic function call (i.e. something like main) or a side affect of the profiling itself.

What is the purpose of the RtlPcToFileHeader function?

Update: Based on Mike's suggestion, I did break into the running process and the couple times it included RtlPcToFileHeader in the stack trace it seemed somehow tied to a dynamic_cast. I have also changed to question to better reflect that I am trying to determine what RtlPcToFileHeader actually does.

+2  A: 

Just pause it under the debugger. Study the call stack to understand what it was doing and why. Then repeat several times. That will tell you where the time is going and the reasons why.

If that's too low-tech for you, try out LTProf, or any other wall-time stack sampler that reports line-level percent, preferably with a butterfly viewer.

The kind of numbers you are puzzling over is precisely the legacy of gprof.

Mike Dunlavey
Thanks, Mike. I have tried what you indicated and have updated my question to better reflect what I am looking for.
Jesse
@Jesse: I also just reviewed the source code of Very Sleepy, and it appears that it also does, or can do, wall-time stack sampling, and it is capable of displaying individual stack samples. In any case, if it is spending that time doing dynamic_cast, the obvious next question is, what is it casting to? That could be your first "bottleneck".
Mike Dunlavey
@Jesse: According to the on-line doc, that routine takes an instruction address and tries to figure out which image (part of your executable pgm) it is in. One can only guess why it's being called as part of casting, *maybe* part of exception processing. The stack should tell why, if you can read it, but in any case, something in your code is triggering it, so that's what to look at.
Mike Dunlavey