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