GetTickCount / Fehler bei Bereichsprüfung

[DeddyH]

Laut MSDN leider erst ab Windows Server 2008.
[edit] Vielleicht könnte man aber auch auf QueryPerformanceCounter/QueryPerformanceFrequency ausweichen, damit sollte das Problem eigentlich nicht bestehen. [/edit]

[Andidreas]

Wenn ich himitsu jetzt richtig verstanden habe, dann wäre doch meine Berechnung nach dem Casten wieder richtig oder sehe ich das falsch.

Spricht dann was dagegen wenn ich es so lasse wie ich es vorhin gepostet habe? Also den GetTickCount immer so abzufragen:

Delphi-Quellcode:

Integer(GetTickCount())

[himitsu]

Ja, das geht ... also entweder die Variable auf DWORD/Cardinal ändern oder das Funktions-Ergebnis nach Integer casten.

Aber, wie gesagt, du mußt auch bei den Berechnungen auspassen. (auch wenn da die Wahrscheinlichkeit viel kleiner ist, daß du diesen kleineren Zeitraum auch nochmal triffst, dort nach den fast genau 49.7 Tagen)

[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:

Zitat von DeddyH (Beitrag 1243818)

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 :zwinker:, 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 :oops: :oops: :oops:

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