Wie schnell ist Now?

[himitsu]

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

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 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 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 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 .

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

(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 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 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 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.

......

[Sprint]

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.