Hotspots in unexpected/weird lines of code

Hotspots in unexpected/weird lines of code

Hi all,

I use Amplifier XE to profile a larger code project. I started with a hotspot analysis and a general exploration for Nehalem CPUs. What puzzles me, both experiments show resuts/hotspots (also bad CPI rates) in unexpected/weird code lines:

1) I see a hotspot (i.e. a large portion of CPU time spent) in a line, where a boolean variable is declared
bool myBool = FALSE;

2) I see another hotspot on a line that only contains the opening { of a function...

I don't really know what to optimize in these lines ;)
Can anybody explain that or point me to a resource where I can do further reading? I checked the forum but didn't find anything... and it's hard to know what to search for.

Thanks a lot!
- tim

5 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Hi Tim,

This may occur due to "event skid" inhardware-based collections:

In this case you can look for real hotspot at several lines near the "weird" place.
For morecertain line informationtake a look at precise events:


Hi Kirill,

you mention "hardware-based collection". I am wondering, whether the same event skid occurs with the standard hotspot analysis which is - as I understand it - not using hardware performance counters.

I havent't been able to collect precise events yet, but I am working on it.

- tim

Yes, standard Hotspots is user-more sampling analysis, as well as Locks and Waits and concurrency. Only hardware-based collections, also called EBS (Event Based Sampling) use events from Performance Monitoring Unit of CPU. So there is no event skid in Hotspots analysis (but event skid may occur in Lightweight Hotspots, that is EBS).


If you compile with in-lining (even with normal defaults), association of hot spots with source code may be problematic.

Leave a Comment

Please sign in to add a comment. Not a member? Join today