Wie schnell ist Now?

[tn249]

Hi

mich würde interessieren wie schnell die funktion Now aus der unit DateUtils ist und ob es sich lohnt den wert von now in eine extra varible zu speichern und dann mit bestimmten werten zu vergleichen oder now jedesmal direkt aufzurufen

MfG
tn249

[Hansa]

Benutze es doch direkt ohne Variable. 8)

[tn249]

Tu ich doch, aber mein Programm prüft Now rel. oft und der PC is lahm, sodass ich mir darüber gedanken machen muss

[alcaeus]

Hi tn249,

wenn dein Programm immer die aktuelle zeit benötigt, dann verwende Now direkt. Falls du mit einer Zeit mehrere Berechnungen durchführen musst, und die Zeit dabei von großer Bedeutung ist, dann verwende eine Variable.
Ich hoffe ich hab dich jetzt nicht noch mehr durcheinandergebracht :mrgreen:

Greetz
alcaeus

[himitsu]

Also normalerweise ist now in der Lage in Millisekundenschritten zu arbeiten, aber aus technischen Gründen arbeitet Now nur in 10-Millisekundenschritten.

Zur Verwendung: machst wie alcaeus sagte, also wenn die selbe Zeit in mehreren Operationen verwendet wird, dann nimm 'ne Variable.

[Nikolas]

Die 10-Millisekunden-Schritte sind aber Rechnerabhängig. Bei mir z.B. hab ich bemerkt, dass nur alle 16ms now aktualisiert wird.

[himitsu]

könnte stimmen ... jetzt wo du's sagst hatten wir (glaub ich) schonmal 20, oder 25ms

Also weniger als 1ms wird es nie - ist Aufgrund der inneren Aufbaus von Now nicht möglich, aber die wird wohl nie erreicht.


PS: ich hab mal 'ne Messreie gemacht und dort ging es in 10ms-Schritten, aber wenn ich die jetzt wiederhole, dann sind es zwar weiterhin 10ms, allerdings immer in 'nem anderen Bereich (also einmal ist es z.B. 3-13-23-33... und ein anderes Mal z.B. 7-17-27-37... :gruebel: , oder eben anders)

[edit]
OK, ich hab's, warum sich das bei mir so "eigenartig" ändert - es sind halt nicht genau 10ms (bei mir), sondern durchschnittlich eben 10.015 ms (und in meiner kurzen Messreihe ist der Sprung zufällig nie aufgetaucht) :wall:

[tn249]

also kann man davon ausgehen das now ca 10 ms sec braucht

da frage ich mich jetzt wenn wir schon dabei sind das so genau zu erläutern wie schnell eine variable in der der wert von now gespeichert werden kann initialisiert werden kann und wie schnell eine wertzuweisung ist

und wenn mans jetzt ganz genau haben möchte müsste man ja noch den prozessor mit einbeziehen, da ja nichtnur die taktfrequenz entscheidend ist sondern wie schnell der prozessor die verschiedenen basis rechenoperationen durchführen kann,
--ich meine mich zu erinnern dass es da bautypen spezifische unterschiede gibt, aber das lassen wir jetzt besser aussen vor

MfG und Danke schonmal
tn249

[himitsu]

Wer wissen möchte, wie schnell nun bei ihm Now reagiert, der kannst ja mal von Windows erfragen (siehe Demo), oder er mist nach (siehe Codeschnipsel)

Das Codeschnipsel
Benötigt wir ein Button (Button1) und ein Editfeld (Edit1).

Ausgegeben wird die durchschnittliche Dauer (in Millisekunden).

Gemessen werden 1000 Zyklen (kann notfalls geändert werden), was bei 10ms Zyklusdauer etwa 10 Sekunden dauern sollte.

Delphi-Quellcode:

Procedure TForm1.Button1Click(Sender: TObject);
  Var T, N: TTime;
    A: Integer;
    S: TTime;

  Begin
    S := Now;
    T := S;
    A := 0;
    While A <> 1000 do Begin
      N := Now;
      If N <> T Then Begin
        T := N;
        Inc(A);
      End;
    End;
    Edit1.Text := FloatToStr((N - S) * MSecsPerDay / A);
    Beep;  Sleep(250);  Beep;  Sleep(250);  Beep;
  End;

Die Demo
Auf Seite 2 steht unter SystemTimeAdjustment / TimeAdjustment & TimeIncrement der Wert (Bedeutung siehe GetSystemTimeAdjustment)

[dizzy]

Zitat:

Zitat von himitsu

Delphi-Quellcode:

While True do Begin;
  N := Now;
  If N <> T Then Begin
    T := N;
    Inc(A);
    If A = 1000 Then Break;
  End;
End;

*shiver* so ganz nach Styleguide ist ja ja nicht, woll!? Und eine recht komische Form einer repeat..until-Schleife dazu :roll:; und was macht das ';' hinter 'begin'?? Und Schlüsselwörter mit Großbuchstaben beginnen, Variablen groß, 'Begin' in der Zeile des Schleifen/Bedingungs-Kopfes... ich glaube, du hast es geschafft in diesen paar Zeilen so gut wie möglich dem Styleguide aus dem Weg zu gehen :zwinker:

Delphi-Quellcode:

repeat
  n := now;
  if t <> n then
  begin
    t := n;
    inc(a);
  end;
until a = 1000;

fände ich da schöner 8)


Das, und auch nur aus Gründen der Ästhetik, nur am Rande! :cheers: nicht bös gemeint!

gruss,
dizzy


\\edit: Und dann noch sowas:

Delphi-Quellcode:

  Beep;  Sleep(250);  Beep;  Sleep(250);  Beep;

*kopfschüttel* ;)

[himitsu]

Uups ein ; ... da ist wohl beim Löschen doch was zurückgeblieben :oops:

Das Break stammt noch aus 'ner optimierteren Version - der Vergleich muß halt nicht unbedingt bei jedem Schleifendurchlauf gemacht werden, deshalb ist der halt dorthin verschoben, wo der sinnvoll ist.

Die Beep's ... naja, ist halt 'ne Eigenart von mir.
1. was "sinnvoll" zusammengehört, schreib ich eben so, dass es optisch auch zusammengehörig ist (und wenn's passt, kommt es eben hintereinander in eine Zeile).
2. bei Prozessen, welche länger dauern und wo es keine eindeutige Rückmeldung gibt, ob dieser schon fertig ist, da kommt eben an's Ende ein akustisches Signal.

Und was den sogenannten Styleguide angeht:
1. gibt es tausende davon, wo jeder irgendwie was anderes sagt.
2. sind das keine Befehle, sondern nur Hinweise, welche man beachten kann (wenn man will).
3. eignet sich halt jede(r) einen Style an, mit welchem er/sie eben am Besten zurechtkommt und ein bissl künstlerische Freiheit steht doch wohl jedem noch zu.


Das optimiertere Teil (es wurde halt nur einiges wegoptimiert):

Delphi-Quellcode:

Procedure TForm1.Button1Click(Sender: TObject);
  Var SystemTime: TSystemTime;
    Milliseconds: Word;
    A: Integer;
    S: TTime;

  Begin
    GetLocalTime(SystemTime);
    Milliseconds := SystemTime.wMilliseconds;
    With SystemTime do S := EncodeTime(wHour, wMinute, wSecond, wMilliseconds);
    A := 0;
    While True do Begin
      GetLocalTime(SystemTime);
      If SystemTime.wMilliseconds <> Milliseconds Then Begin
        Milliseconds := SystemTime.wMilliseconds;
        Inc(A);
        If A = 1000 Then Break;
      End;
    End;
    With SystemTime do 
      Edit1.Text := FloatToStr((EncodeTime(wHour, wMinute, wSecond, wMilliseconds) - S) * MSecsPerDay / A);
    Beep;  Sleep(250);  Beep;  Sleep(250);  Beep;
  End;

[Luckie]

Aber aus Gründen der Lesbarkeit, hatman sich wohl in der OIpenSource gemeinde weithin auf den Borland Object Pascal StyleGuide geeinigt: http://www.luckie-online.de/Artikel/...yleGuide.shtml

[dizzy]

Zitat:

Zitat von himitsu

Das Break stammt noch aus 'ner optimierteren Version - der Vergleich muß halt nicht unbedingt bei jedem Schleifendurchlauf gemacht werden, deshalb ist der halt dorthin verschoben, wo der sinnvoll ist.

Wo du's sagst... das sehe ich ein - okay!

Zitat:

Zitat von himitsu

Die Beep's ... naja, ist halt 'ne Eigenart von mir.
1. was "sinnvoll" zusammengehört, schreib ich eben so, dass es optisch auch zusammengehörig ist (und wenn's passt, kommt es eben hintereinander in eine Zeile).
2. bei Prozessen, welche länger dauern und wo es keine eindeutige Rückmeldung gibt, ob dieser schon fertig ist, da kommt eben an's Ende ein akustisches Signal.

Die Beeps sind ja okay (ShowMessage ist aber auch hübsch ;)), nur in einer Zeile... mich würd's irritieren. Und zum Durchsteppen auch nicht so gut geeignet, oder?

Zitat:

Zitat von himitsu

Und was den sogenannten Styleguide angeht:
1. gibt es tausende davon, wo jeder irgendwie was anderes sagt.
2. sind das keine Befehle, sondern nur Hinweise, welche man beachten kann (wenn man will).
3. eignet sich halt jede(r) einen Style an, mit welchem er/sie eben am Besten zurechtkommt und ein bissl künstlerische Freiheit steht doch wohl jedem noch zu.

1. Ich spreche von dem einzigen mir als semi-gültig bekannten: Dem, der bei Borland zu finden ist.
2. Es sind Empfehlungen die Code besser lesbar machen sollen, und zu einem einheitlichen Code-Bild führen, so dass ein Nicht-Autor trotzdem schnell einen Überblick bekommt. Letztlich ist es natürlich an einem selbst, wie er's hält. Ich hab mir nur den Styleguide-Stil angewöhnt um leichter Code weitergeben zu können, und ich muss sagen: Es half mir auch selber bei der Übersichtlichkeit des Codes. Der StyleGuide ist schon nicht so schlecht durchdacht!
3. Ja klar, hier und da breche ich auch mit den Quasi-Regeln. Aber bei zu viel künstlerischer Freiheit taugt der Code vielleicht zum Kompilat, aber auf keinen Fall zur Weitergabe :zwinker:.

Bin halt jemand, der sich immer über leicht lesbaren Code freut, und er wird leichter lesbar durch ein bekanntes Codebild - ganz subjektiv.
Es will dir ja keiner, und insbesondere ich nicht, etwas vorschreiben. War nur ein kleiner Hinweis am Rande :angel2:

(Es gab mal irgendwo einen Wettbewerb in Sachen "Code-Obfusicating" - allerdings in ANSI C. Da waren vielleicht Klamotten bei... ei ei ei. Da hätte man einen Ausdruck des Listings als Gemälde verkaufen können *g*)

[himitsu]

Zitat:

Zitat von dizzy

Die Beeps sind ja okay (ShowMessage ist aber auch hübsch ;)), nur in einer Zeile... mich würd's irritieren. Und zum Durchsteppen auch nicht so gut geeignet, oder?

ShowMessage ist auch nicht schlecht, aber bei für mich selber, oder für billige Testcodes - wozu erst noch so ein störendes Fenster aufspringen lassen, wenn's auch so ausreicht ^^
Und das Durchsteppen ... also ein Schritt = ein Dreifachbeep
und die Fehlersuche an solchen Stellen - also wenn bei sowas wirklich mal ein Fehler auftaucht und dieser nicht gleich auf den 1. Blick erkennbar ist, dann geh ich besser in Rente ... nein im ernst: Probleme hab ich dort noch keine gehabt und es kann auch mal Vorteile haben - vorallem bei aufeinanderfolgenen und ähnlichen Befehlen und dazu wird der Quellcode auch noch ein bissl kürzer, oder anders gesagt, es passt dadurch ein größeres Stück Code in den selben Fensterausschnitt rein ...
Das in der Demo zeigt, was ich meine und find es halt so sehr viehl übersichtlicher.

nochmal zum StyleGuide:
ich versuch es ja dennoch übersichtlich zu machen, aber es hatte sich halt im laufe der Jahre einiges "komisches" eingeschlichen und gewisse Macken wegzubekommt ist nicht leicht, aber ich hab's wenigstens geschaft vieles zu vereinheitlichen.
Und wie schon gesagt, gibt es viele schlimme Sachen und dagegen ist das ja noch extem übersichtlich

[Sprint]

Zitat:

Zitat von tn249

mich würde interessieren wie schnell die funktion Now aus der unit DateUtils ist

Sehr schnell. Kannst du selber mit QueryPerformanceCounter messen.

Zitat:

und ob es sich lohnt den wert von now in eine extra varible zu speichern

In einer Schleife? Ja!
Aber ist natürlich abhängig wie oft du Now aufrufst. Hatte mich selber über das Ergebnis gewundert.
Und hätte eigentlich gedacht, das die Funktion Now um ein vielfaches langsamer ist. So kann man sich täuschen.

[Jelly]

Hallo,

also wenns schneller gehen soll, dann nutzt man besser Gettickcount, das geht nämlich wirklich im ms-Takt. Es ist aber nicht die Funktion "now" die solange rechnet, um die Zeit auszugeben, sondern von wo die Zeit genommen wird, und die steht im BIOS, wenn ich mich gut erinnere. Unter DOS Zeiten konnte man irgendwie an den IRQ rumfriemeln (ist schon lange her), und man konnte somit auch eine bessere Zeitauflösung hinbekommen, als eben diese besagte 16ms (oder warens 13, egal). Dafür lief die Uhr dann aber schneller auf dem System...

Naja, jedenfalls will ich damit sagen, wenn eine höhere Zeitauflösung gefragt ist, dann besser Gettickcount benutzen.

Gruß,

[sakura]

Zitat:

Zitat von Jelly

also wenns schneller gehen soll, dann nutzt man besser Gettickcount, das geht nämlich wirklich im ms-Takt.

Ich muss Dich korrigieren :? GetTickCount unterliegt den gleichen Beschränkungen denen auch Now unterliegt. Beide Sind vom internen Timer abhängig. Wie genau die Auflösung für den einzelnen PC ist, dass erfährst Du mithilfe der Funktion GetSystemTimeAdjustment.

@tn249: Geht es Dir um die Geschwindigkeit von Now? Dann kannst Du viele Abrufe innerhalb einer Millisekunde tätigen, das fällt nicht auf. Geht es Dir um die Genauigkeit, dann ist Now nicht der beste Weg, sondern eher Dinge wie QueryPerformanceCounter etc.

...:cat:...

[Sprint]

Zitat:

Zitat von Jelly

Es ist aber nicht die Funktion "now" die solange rechnet, um die Zeit auszugeben, sondern von wo die Zeit genommen wird, und die steht im BIOS, wenn ich mich gut erinnere.

Ich hab' die Zeit gemessen. 0,05 Millisekunden beim ersten Aufruf. Da kann ich ganz schön oft Now Aufrufen bis ich eine Millisekunde zusammen hab.
Was will man da noch optimieren?


Edit: Falls es jemanden interessiert wie ich gemessen hab...

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var
  Frequenzy, Start, Stop: Int64;
  DateTime: TDateTime;
begin

  // Erste Messungen - Ergebnis sollte bei 1000 liegen
  QueryPerformanceFrequency(Frequenzy);
  QueryPerformanceCounter(Start);
  Sleep(1000);
  QueryPerformanceCounter(Stop);
  ShowMessage(FormatFloat('0.000', (Stop - Start) * 1000 / Frequenzy));


  // Zweite Messungen - Mal sehen wie schnell Now ist
  QueryPerformanceFrequency(Frequenzy);
  QueryPerformanceCounter(Start);
  DateTime := Now;
  QueryPerformanceCounter(Stop);
  ShowMessage(FormatFloat('0.000', (Stop - Start) * 1000 / Frequenzy));

  DateToStr(DateTime);

end;

[tn249]

na die zeitauflösung reicht wenn sie auf ne halbe sec genau is, aber in der zeit will ich min 20 mal now vergleichen

werd wohl den wert von now inner variablen speichern

MfG
tn249

[glkgereon]

ähm, was spricht gegen so eine messweise?

Delphi-Quellcode:

start:=time;
for i:=1 to 999999 do x:=now;
stop:=time;

oder gegen eine solche konsolenanwendung?

Delphi-Quellcode:

zeit:TDateTime;
  i:Int64;

begin
  Werte:=TStringList.Create;
  writeln('Es wird nun die Geschwindigkeit von now 1 Minute lang getestet...');
  zeit:=now;
  while (now<zeit+0.000694444444) do inc(i);
  writeln('Es wurden '+inttostr(i)+' Versuche geschafft...');
  writeln('-> '+floattostr(i / 60)+' pro Sekunde...');
  writeln('-> '+floattostr(60000 / i)+' Millisekunden pro Durchlauf...');
  readln;
end.

[FAlter]

Wisst ihr, wie Now implementiert ist?

Delphi-Quellcode:

Result := Date + Time;

Ich denke, man sieht, wie leicht sich ein paar Ticks sparen lassen. Und GetTickCount ist dann, wenn es nur auf Millisekunden ankommt, vermutlich die bessere Wahl (unbewiesene Behauptung). Bei noch genauerer

PS: Schade, dass delphi keine Makros kann :(

[glkgereon]

Delphi-Quellcode:

    writeln('Es wird nun die Geschwindigkeit von "now" 1 Minute lang getestet...');
    zeit:=now;
    while (now<zeit+1/24/60) do inc(i);//1=tag /24=stunde /60=minute
    writeln('Es wurden '+inttostr(i)+' Versuche geschafft...');
    writeln('-> '+floattostr(i / 60)+' pro Sekunde...');
    writeln('-> '+floattostr(60000 / i)+' Millisekunden pro Durchlauf...');

also das is mein qt...

bei dem kommt immer in etwa dasselbe raus
beispiel:
90162736 Versuche
1502712,26666667 pro Sekunde
0,000665463390551946 Ms pro Durchlauf
-> für "ein Now" weniger als 0,001 Ms

kann das sein?

EDIT:

Es kommt noch schlimmer: in einem Dauerlauf sinkt die zeit kontinuierlich...
hier meine logfile, in der ich von jeder runde meinen zähler speicher (welcher immer höher steigt):

Zitat:

15425227
31223342
44994514
59589841
75048739
90764494
105974080
121638413
136844801
149813096
164240349
178464597
193157262
208506152
223825834
239124542
254333749
269997018
285589556
300514267

die letzte zahl bringt es auf unter 3,3 E-5 Ms pro Now

wo ist der fehler in meinem quelltext?

[Sprint]

Zitat:

Zitat von glkbkk

wo ist der fehler in meinem quelltext?

Zuerst einmal musst du wissen was die Funktion Now macht. Now ruft intern die WinAPI Funktion GetLocalTime auf.
Diese Funktion steckt in der KERNEL32.DLL Datei.
Dieser Wert wird aber nur in einem bestimmten Takt erneuert. Wenn du also in einer Schleife eine Minute lang aufrust,
dann ist einmal das System ausgelastet und du verfälscht dadurch die Geschwindikeit von Windows. Hinzu kommt noch, das der interne Wert von GetLocalTime nicht bei jedem Aufruf erneuert wird.
Also wirst du so nie eine genaue Zeitmessungen durch führen können.

[glkgereon]

ja gut, aber es geht mir ja nicht darum die zeit zu nehmen, sondern darum, wie lange now braucht, und dies verkürzt sich mit zunehmender laufzeit ins unrealistische, hier mein aktueller log:

Zitat:

15425227
31223342
44994514
59589841
75048739
....
2508025096
2523343282
2538599782
2553783069
2568940084

beim letzten mal braucht er nur noch 0,000003715 Ms

danach wird windows im aufrufen dieser funktion jedes mal ein klein wenig besser...
find ich irgendwo unlogisch...