High Performance Counter vs. GetThreadTimes
-
Hi,
Ich möchte während des Programmablaufs die Rechenzeit bestimmter Komponenten messen und eine Statistic erstellen.Hierfür habe ich mir eine Klasse geschrieben, bei der vor und nach den zu messenden Codeteilen ein start und stop aufgerufen wird und die die gemessene Zeitdifferenzen aufakkumuliert.
die Zeiten messe ich mittels GetThreadTimes, da ich verhindern möchte, dass ich Taskswitches oder sowas mitmesse.
Allerdings scheint mir die Auflösung recht gering zu sein, da ich vor allem bei geringer Last sehr oft 0 bekomme.
Der High-Performance-Counter auf der anderen Seite hat zwar eine super Auflösung, aber zählt natürlich Echtzeit und nicht Processorzeit.
Gibt es eine Lösung für das Problem?
PS:
Betriebssystemanforderung wäre WinXP oder höher.
-
Eine ähnliche Diskussion gab es bereits hier.
Leider scheint es darauf hinauszulaufen, dass eine Genauigkeit in Millesekunden ausreichen muss.
-
Hmm, ich habs befürchtet.
Trotzdem: danke für den Link, dort war ich noch nicht gelandet.
-
Siehe auch mein Blogeintrag:
http://blog.kalmbachnet.de/?postid=28
-
Jochen Kalmbach schrieb:
Siehe auch mein Blogeintrag:
http://blog.kalmbachnet.de/?postid=28Danke.
Aber jetzt bin ich völlig ratlos.
Was kann man sonst tun, um die verbrauchte Rechenzeit zu ermitteln?http://blog.kalmbachnet.de/?postid=28 schrieb:
So, a thread should never go into wait-states or should be interrupted by other (higher) priority threads.
Der erste Teil ist irrelevant. Der Code um den es geht, der rechnet einfach nur.
Auch sind 10ms natürlich viel zu grob (die Gesamtzeit aller Module darf nicht länger als ~30ms betragen). In dem Bereich schlagen mitgemessene Threadwechsel natürlich auch ordentlich zu Buche.
-
Der relevanmte Teil ist doch:
GetThreadTimes will only produce correct values, if each thread would consume all of its quantum
Du kannst versuchen ob ein "timeBeginPerdiod(1)" hilft...
-
Jochen Kalmbach schrieb:
Der relevanmte Teil ist doch:
GetThreadTimes will only produce correct values, if each thread would consume all of its quantum
Klar.
Danach hast du die Gründe aufgeführt:
Der Thread geht in ein Wait: wird nicht passieren, aber da der Thread sich selbst misst, misst er auch immer das aktuelle Quantum nicht mit.Der Thread wird durch Höherpriores unterbrochen: Kann immer passieren. Hier hab ich allerdings nicht verstanden: das bekommt doch der Scheduler mit, warum sollte die in diesem Quantum bisher verbrauchte Zeit nicht mitgezählt werden?
Jochen Kalmbach schrieb:
Du kannst versuchen ob ein "timeBeginPerdiod(1)" hilft...
dadurch taskswitcht er ja noch öfter.
Klar die Auflösung wird besser (trotzdem nur 1ms) und das aktuell angefangene Quantum fällt auch nicht mehr so ins Gewicht. Aber dem OS so ins Handwerk zu pfuschen?
-
Es ist halt so implementiert, dass die Zeit dem Thread zugeschlagen wird, der sein Quantum ausschöpft... hätte man vielleicht auch anders machen können, hat man aber nicht
