Ausgabe der Zeit (in ms) welche eine Procedur benötigt

[eagle1985]

Hallo zusammen,

ich benötige eine Funktion welche es ermöglicht anzuzeigen wie lange eine Procedure/Funktion läuft.

habe mir so etwas vorgestellt:

Code:

StopTime.start;
try
  Proceudre TuIrgendWas
finally
  ShowMessage(StopTime.Stop)
end;

Habe es bereits mit den Delphi-Funktionen getTime und DateToStr(now) versucht.
Hatte leider keinen erfolg, da anscheinend nur die Uhrzeit auf Sekunden ebene ausgegeben wird.

Hat jemand eine andere Idee wie dies zu bewerkstellen ist.
Kann man in Delphi Timestamps machen wie in Unix oder SQL welche in ms arbeiten?
Dan bräuchte ich die beiden TimeStamps nur von einander zu Subtrahieren und hätte die Zeit in ms

greez eagle

[runner]

Probier doch mal die Funktion GetTickCount. Die Liefert die die Zeit seit Systemstart im 1/1000 sec.

[hsg]

Die Funktion GetTickCount() aus dem Win-API hilft dir dabei:

Delphi-Quellcode:

procedure Test();
var
  start : Cardinal;
  dauer : Cardinal; 
begin
  start := GetTickCount();
  // Mach was langes
  dauer  := GetTickCount() - start;
end;

[Vjay]

Schau mal in die Hilfe zu "getTickCount", aber achtung dies ist nicht die benötigte Prozessorzeit, sondern dann die reale Zeit.

also, da ich gerade gute Laune habe:

Delphi-Quellcode:

var
 startZeit, endZeit: cardinal;
begin
 startZeit:= getTickCount;

// hier mach, was du machen musst

 
 endZeit:= getTickCount;
 if endZeit > startZeit then endZeit:= endZeit -getTickCount
 else endZeit:= 0; // kann selten vorkommen, grund siehe windows-hilfe
end;

[JasonDX]

Zitat:

Zitat von Vjay

Delphi-Quellcode:

if endZeit > startZeit then endZeit:= endZeit -getTickCount
else endZeit:= 0; // kann selten vorkommen, grund siehe windows-hilfe

Na ja, wenn wir schon ruecksicht darauf nehmen, dann auch richtig ;)

Delphi-Quellcode:

if endZeit > startZeit then
  endZeit := endZeit - startZeit
else
  endZeit := (high(cardinal) - startZeit) + endZeit;

Kommt allerdings erst zu tragen, wenn das System fuer knapp 50 Tage laeuft und die Kapazitaet von nem DWord ausgereizt ist ;)

greetz
Mike

[eagle1985]

danke für die Hinweise auf getTickCount, hab gar nicht gewusst dass es diese Funktion gibt.
Damit kann ich mein Problem lössen.

THX

[xaromz]

Hallo,

vielleicht noch ein Hinweis: GetTickCount ist nicht so hochauflösend, wie das Ergebnis glauben macht, da die Auflösung vom Systemtimer abhängig ist. Dieser arbeitet aber meist mit weit geringerer Auflösung als 1 ms. Mit GetSystemTimeAdjustment lässt sich dieser Wert herausfinden.
Evtl. wäre QueryPerformanceCounter zusammen mit QueryPerformanceFrequency besser. Die erreichte Auflösung geht ja nach PC bis zur Prozessorfrequenz.

Übrigens: Für das Überlaufproblem nach ~50 Tagen gibt es natürlich eine Lösung: GetTickCount64!

Gruß
xaromz

[himitsu]

49,7 :angel2: , obwohl meistens die Programmteile nicht solange laufen, vorallem nicht wenn jemand die Zeit in ms benötigt ;)

[xaromz]

Hallo,

Zitat:

Zitat von himitsu

49,7 :angel2: ,

Klugscheisser :mrgreen: .

Zitat:

Zitat von himitsu

obwohl meistens die Programmteile nicht solange laufen, vorallem nicht wenn jemand die Zeit in ms benötigt ;)

Das Problem ist ja nicht, dass ein Programmteil so lange läuft, sondern, dass das System genau zwischen dem ersten und dem zweiten Messpunkt 49,7 Tage gelaufen ist. Dann ist der erste Wert z. B. 4 Mrd, und der zweite 10.

Gruß
xaromz

[Vjay]

Jop, aber bevor man in 50 Tagen den Fehler sucht, ne ;)

Übrigens habe ich ja totalen Humbug geschrieben:

Delphi-Quellcode:

if endZeit > startZeit then endZeit:= endZeit - STARTZEIT

so ist das richtiger.

[himitsu]

Selbst wenn Windows schon über 49,7 Tage gelaufen ist, oder erst wärenddessen den prung über diese Grenze macht, so bekommt man bei der Division dennoch die Riochtige Diverenz raus, solange der Messzeitraum nicht selber länger dauert.

1000-900=100

50-4294967246=100

Man darf nur nicht mit Fließkommawerten, oder In64 rechnen ... innerhalb von LongWord/Cardinal gibt es dann wärend der Berechnung wieder einen Überlauf, welcher den vorherigen behebt :zwinker:

[Luckie]

Nun ja, so viel zur geplanten Laufzeit und deren Folgen, wenn die nicht beachtet wird:

Zitat:

Golfkrieg, Februar 1991:
In Dhahran, Saudi-Arabien, konnte eine irakische Scud- Rakete nicht vom hochgelobten Patriot-Abwehrsystem abgefangen werden - sie schlug in ein US-Militärlager ein und tötete 29 und verwundete 97 US-Soldaten
Ursache: Die "Realzeit seit letztem Booten" der Software der Patriot-Rakete wurde in einer einfachgenauen Gleitkommazahl abgespeichert. Lief das System länger als 8 Stunden (etwa 30 Millionen ms), traten daher Genauigkeitsprobleme auf:
Nach 100 Stunden Laufzeit ergab der immer größer werdende Zeitfehler eine Abweichung in der Berechnung der Scud-Flugbahn um 678 m
Das Design der Software sah nur 14 Stunden Einsatz vor.

Also der Hinweis ist schon nicht falsch an dieser Stelle.

[himitsu]

Zum Glück arbeitet hier keiner mit TDateTime/TTime (doppelte Genauigkeit), sondern mit 'nem netten vorzeichenlosen Integer (ohne Genauigkeitsprobleme) :angel: