Comments are closed.
Recent Posts
Tags
asm
Bottleneck
Breakpoint
Bugfix
Changelog
CodeGear
Command
Compiler
CPU
Debug
Delphi
Download
DWS
FireMonkey
Forums
Fractals
FreePascal
GLScene
IDE
JavaScript
JIT
L-System
MAP
MapFileStats
Monitor
Newsgroup
OP4JS
Optimization
OutputDebugString
Poll
Profiler
Real-time
RTTI
Screenshots
Site
Size
SmartMS
SynEdit
threadID
Tips
TMonitor
Tools
Unicode
WordPress
XML


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).