Version 1.8.0 of SamplingProfiler is now available.
The options dialog now support Delphi XE2 & Delphi XE3 search/browse paths, other changes are only indirect fixes/improvements related to the components and libraries used in SamplingProfiler.
SamplingProfiler 1.8.0
Copyright in the status bar still shows 2011 😉
Does the added support for XE2/XE3 search-paths also mean that we can profile 64 bit executables?
And about the sampling itself: With so many cores nowadays, why ‘only’ 1000 samples per second? If its a timer-related issue, then maybe this can help : http://www.geisswerks.com/ryan/FAQS/timing.html
@Patrick van Logchem
No, 32 bits only. I attempted a 64 bit port, but the Delphi 64 bit debugger was way too unstable, so I gave up.
The frequency limit comes from timeSetTime, the multimedia timer, whose highest frequency is 1kHZ. The other timers unfortunately don’t seem to be reliably fired at a fixed interval, but are delayed by minutes amounts and fall on kernel time slices, which skews the results somewhat.
CreateTimerQueueTimer, the successor to timeSetTime, has the same limits.
Also the problem isn’t as much the number of cores, but the CPU frequency, which hasn’t gone up much. Number of cores could be leveraged when sampling multi-threaded apps, though I haven’t investigated those much as the results can be quite complex to interpret.
@Eric
Yeah I suspected as much, that’s why I posted that link – it describes a method to get very accurate timing, beyond what’s possible with the normal windows timers. It does require rolling your own busy-wait loop, but when you apply SetProcessorAffinityMaskForThread the measuring thread to a dedicated core, the profiled app won’t notice.
As for 64 bit support, for me it’s worth my time to assist, so mail me if you want at pvanlNOSPAMogchem at gmNOSPAMail dot com (remove OBVIOUS characters).