Delay zu langsam?

[negaH]

Ja das sind so Sachen die passieren wenn man solche Tests auf einem System macht das im Grunde unberechenbar ist. Zb. deine zweite Schleife liefert auf den ersten Blick erstaunliche und wenig verständliche Resultate. Wenn man aber weiß was der Aufruf von Sleep() bedeutet wird das dann klarer. Sleep(0) zb. ist ein sinnvoller Aufruf auch wenn der aktuelle Thread keine 0 Millisekunden schlafen kann. Denn Sleep() führt in jedem Fall einen Task Wechsel aus. Dh. man übergibt programmatisch die Kontrolle an den taskscheduller vom OS und der wird einen Taskwechsel zu einem anderen Task durchführen. Nun entfernst du aber in der 2. Schleife nicht per .ProcessMessages die Nachrichten im Messagequeue und der läuft quasi voll. Das OS scheint nun dafür immer mehr Resourcen zu benötigen, zb. für die Verwaltung dieser Nachrichten und schwups wird der komplette Prozess ausgebremmst.

Durch den Overhead der zusätzlichen API Funktionen in meinem Delay() wird es ebenfalls zu einer Verschlechterung der Perfomance kommen, je kürzer die Wartezeit wird.

Zudem ist das Application.ProcessMessages ebenfalls eine "Störquelle". Diese Funktion kehrt abhängig von der Messageabarbeitung zurück. Es könnte also zb. Nachrichten geben die in einer Schleife enden. Zb. viele der Nachrichten für den Non Client Bereich von Fenstern verzweigen intern in Schleifen und geben die Kontrolle an den Aufrufer erst zurück wenn sie es wollen. Klicke und Ziehe zb. mal in den Fensterrahmen und lass die Maustaste gedrückt. Intern wird in eine Schleife verzweigt, im Windowskernel, die erst bei Loslassen der Maus zurückkehrt.

Deswegen, und noch vielen anderen Nachteilen, würde ich auf den Aufruf von Applikation.processMesages im eigenen Source oder Komponenten etc.pp. absolut verzichten. Ebenso wie ein Delay() um auf irgendwas zu warten. Das sind alles "Tricks" die kontraproduktiv sind. Kontraproduktiv weil es auch anders und weit besser geht. Zb. einen Timer per Messages oder Callback Funktion zu benutzen oder mit den Events des OS arbeiten, zb. bei fast allen Kommunikationsschnittstellen ist das möglich. Im schlechtesten Fall muß man eben einen Thread abspalten und kann in diesem ohne Messagequeue und Sleep() und Events sicher arbeiten. Man stellt also in jedem Fall das System auf Events um statt zu Pollen.

Gruß Hagen

[Schorschi5566]

Hallo Hagen,

Zitat von Hagen:

Nun entfernst du aber in der 2. Schleife nicht per .ProcessMessages die Nachrichten im Messagequeue und der läuft quasi voll.

Nö. Macht doch Dein Delay.

Delphi-Quellcode:

procedure Delay(Milliseconds: integer);
var
  Tick: DWORD;
  Event: THandle;
begin
  Event := CreateEvent(nil, False, False, nil);
  try
    Tick := GetTickCount + DWORD(Milliseconds);
    while (Milliseconds > 0) and (MsgWaitForMultipleObjects(1, Event, False,
        Milliseconds, QS_ALLINPUT) <> WAIT_TIMEOUT) do
    begin
      Application.ProcessMessages; // <-- das ist er doch...der Aufruf!
      if Application.Terminated then Exit;
      Milliseconds := Tick - GetTickCount;
    end;
  finally
    CloseHandle(Event);
  end;
end;

Zitat von Hagen:

Durch den Overhead der zusätzlichen API Funktionen in meinem Delay() wird es ebenfalls zu einer Verschlechterung der Perfomance kommen, je kürzer die Wartezeit wird.

Ja, das auch, aber das erklärt nicht, warum die Schleife mit Delay(10) ohne Mausrühren exakt 5000ms braucht.

Scheint mir eher so, dass

Delphi-Quellcode:

MsgWaitForMultipleObjects(1, Event, False,
        Milliseconds, QS_ALLINPUT

wesentlich mehr Zeit als Milliseconds verbraucht, wenn die Funktion erstmal ausgeführt wird und Milliseconds < 50ms ist. Da liegt der Hase im Pfeffer und die Beschreibung der API-Funktion sollte vielleicht lauten, dass die Funktion wenigstens 50ms verbrät, wenn eine Message vorliegt.

Und damit wartet Delay < 50ms eben länger als erwartet, wenn viel los ist. Nicht mehr und nicht weniger.


Viele Grüße,
Uwe

[negaH]

Jo wäre auch eine Erklärung, aber ohne den Source dieser Funktionen ist das Raten

gruß Hagen

[Schorschi5566]

Na ja, was soll die Funktion schon machen, wenn eine Message vorliegt?

Sie wird sie halt abarbeiten und dabei sicherlich nicht ständig auf die Uhr schauen.

Eventuell sollte man bei Milliseconds < 50 einfach den Aufruf von MsgWaitForMultipleObjects weglassen dann würde es immerhin zeitlich bis runter zu 10ms passen.

Grüße,
Uwe