Bezüglich Timer:
Statt alle 1000ms zu fragen, ob ein Zeitpunkt erreicht ist, berechne vor dem Einschalten des Timers die Millisekunden, die noch bis zum nächsten "Ausführungszeitpunkt" zu vergehen haben, setze das Timerinterval auf diesen Wert und dann den Timer auf enabled.
Hab' ich mal in 'nem Dienst gemacht, der diverse Aufgaben zu unterschiedlichsten Zeitpunkten zu erledigen hatte. Je Aufgabe ein Timer, dessen Interval berechnet wurde und dann den Timer eingeschaltet. In der Timerroutine wird dann die entsprechende Aufgabe gestartet und anschließend die Millisekunden bis zum nächsten Zeitpunkt berechnet und als Wert für das Interval gesetzt und dann der Timer eingeschaltet. Die "Auflösungsgenauigkeit" hat bei diesem Vorgehen in einem Bereich von +/- maximal 1ms. Trifft letztlich genauer, als alle 1000ms zu schauen, ob ein Zeitpunkt erreicht ist und ist dadurch letztlich auch weniger aufwendig.
Zitat:
Nach dem Klick geht die Sanduhr an und 2..5sec später sieht man am RS232-Sniffer, dass der Befehl raus geht.
Was genau passiert denn letztlich hier. Meine erste Vermutung wäre, dass hier irgendwas genutzt wird, dass sich auf das Laufzeitverhalten auswirken kann. Aber was?
Hatte mal ein ähnliches Problem mit 'nem ollen Rechner, 'nem ollen Delphi und 'nem ollen Windows.
Damals war die Ursache, dass mit steigender Laufzeit immer mehr in der Auslagerungsdatei landete und Windows dauernd von dort die Daten wieder in den Speicher holte (auch wenn das in Taskmanager, ... und den dort sichtbaren Werten für Speicherverbrauch und Nutzung der Auslagerungsdatei nicht unbedingt sichtbar war). Keine Ahnung, ob es derartige Probleme heute auch noch gibt und Du eventuell mit einem Problem in dieser Richtung zu kämpfen hast. In der Wartezeit bitte mal schauen, ob sich im Taskmanager die Werte für "Seitenfehler" bzw. "Änderung der Seitenfehler" stark bewegen. Dann könnte es sich um ein Problem in dieser Richtung handeln. Wie sehen die Werte für E/A-Bytes lesen bzw. schreiben aus? In einem für die Anwendung angemessenen Rahmen?