GetTickCount / Fehler bei Bereichsprüfung

[DeddyH]

Wie von himitsu schon angedeutet musst Du dann aber berücksichtigen, dass der Wert nach 24,85 Tagen negativ wird und GetTickCount nach 49,7 Tagen wieder bei 0 beginnt.

[Andidreas]

Zitat von DeddyH:

Wie von himitsu schon angedeutet musst Du dann aber berücksichtigen, dass der Wert nach 24,85 Tagen negativ wird und GetTickCount nach 49,7 Tagen wieder bei 0 beginnt.

Ok, aber wenn gecastet wird ist das doch egal???
Sorry ich verstehs grad net ganz...

[DeddyH]

Du willst doch sicherlich eine Zeitmessung implementieren. Wenn Du nun mit GetTickCount eine Startzeit ermittelst und wiederum mit GetTickCount eine Endzeit, dann kann es passieren, dass die Endzeit negativ ist und die Startzeit positiv. Wenn Du nun also einfach so subtrahierst, ziehst Du eine positive Zahl von einer negativen ab, erhältst somit eine negative, mit der Du im Grunde nichts anfangen kannst. Um das zu vermeiden, müsstest Du bei der Subtraktion auch wieder beide Werte in DWORD casten. Wäre es da nicht besser, gleich DWORD zu nehmen?

[himitsu]

Casten muß man bei der Berechung eigentlich nicht. Alle Variablen müssen, während der Berechnung, nur den selben Typ besitzen.
Je nach dem, ob Integer oder Cardinal zum Rechnen verwendet wird, gibt es immer irgendwo einen Überlauf, beim Überreiten von High und Low,
was sich dann aber aufhebt, wenn der Wert danach wieder auf den selben Typ beschnitten wird.

Aber dort wird dann wieder die aktivierte Überlaufprüfung zuschlagen , weswegen diese Prüfung dort auf jeden Fall deaktiviert werden muß.


Bei GetTickCount64 kommt dieser Überlauf erst nach 600 Mio Jahren (falls ich mich nicht verschätzt hab).

[Andidreas]

Ok, jetzt hats klick gemacht, peinlich

Also wäre es so sinnvoller?

Delphi-Quellcode:

var
wrdStart, wrdEnd  : DWord;

If gsPerformCheck = 'YES' Then wrdStart := GetTickCount();

If gsPerformCheck = 'YES' Then
Begin
  wrdEnd := GetTickCount();
  gdblTimeDiff := ((wrdEnd - wrdStart)/1000);
  prMsgLog(MySQL_Database, tyINF, 99999, '', FloatToStrF(gdblTimeDiff, ffFixed, 5, 3), 'Delete Master Data Tables', gbBlckInfoMsg);
End;

[DeddyH]

IMO schon, nur bleibt eben das Problem mit der Uptime > 49,7 Tage. IIRC besteht das nicht, wenn man statt GetTickCount QueryPerformanceCounter und QueryPerformanceFrequency verwendet, sofern GetTickCount64 nicht in Frage kommt.

[p80286]

Frage, warum nicht die signifikanten Bits maskieren und davon dann die Differenz bilden?
Da kann mir der Wraparound doch egal sein?

Gruß
K-H

[himitsu]

QueryPerformanceCounter scheint aber auch ein paar Macken zu haben.

In dem Testprojekt vom himXML hatte ich das drin und auf meinem neuen i7 gibt das Ding keine verwertbaren Ergebnisse mehr raus, bzw. die Werte (also Count / Freq) stimmten absolut nicht.
z.B. Mehere Sekunden bis Tage ausgerechnet, aber real nur paar Millisekunden gelaufen oder auch mal andersrum.
Woran das lag, hatte ich auf die Schnelle nicht rausbekommen. (lag eventuell am Switchen der Treads in den 8 Kernen oder am ständigen hoch und runtergetackte der Kerne oder ein bug im Delphi)


Und den RealTimeStampCounter kann man uch schon länger nicht mehr verwenden, seitdem die CPUs dynamisch tackten und da wo der Counter-Takt an den CPU-Tackt gekoppelt ist.
Wenn er überall an die CPU gekoppelt wäre, hätte man damit wenigstens noch die "reale" CPU-Zeit messen können, aber das geht so ja nun auch nicht.

[Andidreas]

d.h. was würdet ihr vorschlagen?

[samso]

Ich hatte das mal so gelöst:

Delphi-Quellcode:

function TimeDiff(TickCount: Cardinal): Cardinal;
begin
  {$ifopt Q+}{$define recoveroverflowcheck}{$Q-}{$endif}
  Result := GetTickCount - TickCount;
  {$ifdef recoveroverflowcheck}{$Q+}{$endif}
end;

Diese Funktion kann nur eine maximal Zeitdifferenz von besagten 49 Tagen auswerfen. Wie lange der Rechner läuft spielt aber keine Rolle.