Programm wird mit Laufzeit immer langsamer

[norwegen60]

Zitat:

Zitat von TomyN (Beitrag 1485196)

'Primitives' Profiling geht auch mit TimeGetTime...

Dazu müsste ich aber wissen wo/was ich loggen will. Das Problem ist aber, dass die Anwendung nach zwei Tagen immer langsam ist. Zwischen zwei 30 Minuten-Intervallen läuft im Programm eigentlich nichts. Ein 1000ms Timer sorgt dafür, dass alle 5s Temp, Rpm, Status ebgefragt werden. Ich habe den Log dieser Daten deaktiviert, so dass keine Daten in DB, VST, Log oder Chart geschrieben werden. Und dann fragt der Timer noch ab, ob der nächste Messintervall erreicht ist (GetTickCount > NextIntervallCount)

Ich habe einen zusätzlichen Button auf die Oberffläche gesetzt, der einfach SendCommand('TPR') ausführt. Nach dem Klick geht die Sanduhr an und 2..5sec später sieht man am RS232-Sniffer, dass der Befehl raus geht. Die Antwort vom Gerät erfolgt unverzüglich.

[Delphi.Narium]

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?

[TomyN]

Oder einen Thread mit einem WaitableTimer, den könnte man sogar mit 'absoluten' Uhrzeiten füttern.
Kann es evtl. sein, dass Du jedesmal einen neuen Timer erstellst?
Ansonsten könnte ich mir noch vorstellen, dass z.B. das USB Interface in den Energiesparmodus geht, das würde aber den Zuwachs nicht erklären.

Ach ja, nicht vergessen, dass GetTickcount nach 42,3(?) Tagen einen 'wrap around' macht und dann GetTickCount > NextIntervallCount erstmal sehr lange false ergibt ..

[Sinspin]

Zitat:

Zitat von norwegen60 (Beitrag 1485201)

Ich habe einen zusätzlichen Button auf die Oberffläche gesetzt, der einfach SendCommand('TPR') ausführt. Nach dem Klick geht die Sanduhr an und 2..5sec später sieht man am RS232-Sniffer, dass der Befehl raus geht. Die Antwort vom Gerät erfolgt unverzüglich.

Und was findet da dann genau statt wenn der Button gedrückt wurde? Wie funktioniert das Senden des Befehls? Wie wird dann die Verbindung zum COM aufgemacht?
Wird die COM Verbindung offen gelassen (wiederverwendet) oder neu erstellt?
Ich hatte vor langer Zeit mal einen Fehler mit einem ESC POS interface. Freigeben und neu erstellen war da die Lösung.

Jeden kleinen Aufruf mit Zeitmessung zu verwanzen klingt zwar erstmal nach arbeit. Aber der Aufwand lohnt sich. Bei mir sind diese Tests dann permanent im Quelltext. Halt deaktiviert via Compilerschalter wenn ich es nicht brauche.
Durch die Zeitmessung sollte es dann auch keinen Tag dauern bis auffält wo es herkommt. An irgend einer Stelle werden die Abstände kontinuierlich zunehmen.

[himitsu]

Delphi-Quellcode:

+/- maximal 1ms

± 8

Sleep und Timer haben standardmäßig eine Auflösung von 15-16ms.
Aber egal ... das merkt eh niemand.

Zitat:

Jeden kleinen Aufruf mit Zeitmessung zu verwanzen klingt zwar erstmal nach arbeit.

Noch ein $IFDEF drumrum, dann kann man es deaktivieren/entfernen, wenn fertig, und hat es für später immernoch da.

[Delphi.Narium]

Zitat:

Zitat von himitsu (Beitrag 1485215)

Delphi-Quellcode:

+/- maximal 1ms

± 8

Sleep und Timer haben standardmäßig eine Auflösung von 15-16ms.
Aber egal ... das merkt eh niemand.

Zitat:

Jeden kleinen Aufruf mit Zeitmessung zu verwanzen klingt zwar erstmal nach arbeit.

Noch ein $IFDEF drumrum, dann kann man es deaktivieren/entfernen, wenn fertig, und hat es für später immernoch da.

Hab' ich mit meinem ollen Delphi 7 über Jahre mitprotokolliert, um zu erfahren, wie groß die Abweichung bei meiner Berechnung ist. War immer im Bereich von +/- 1ms. Daher meine Aussage.

Und ja: Bei hoher Auslastung eines Rechners, passt das nicht mehr so genau. Da bekommt ein Programm halt nicht unbedingt genug Zeit, um pünktlich zu arbeiten ;-)

Und selbst wenn die Abweichung bei 15 - 16 ms liegt, ist das immernoch genauer, als alle 1000ms zu gucken, wie spät es ist und dann ggfls. zu reagieren ;-)

[TomyN]

Ich hatte schon gröbere Abweichung. Aber mit TimerBeginPeriod kann man da schon optimieren.
Aber im Prinzip ist es schon richtig, dass es sich hier nicht um einen Präzisionstimer handelt.

[norwegen60]

Da kommen mehr Anregungen rein als ich auf die Schnelle umsetzen kann. Ein paar Anmerkungen

Das Programm ist recht umfangreich und ich habe es übergeben bekommen. Bin dabei Dinge zu optimieren aber das ist recht mühsam da Funktionen viel zu tief verschachtelt sind.

• Ein Teil der Funktionen die in dem SekundenTimer überwacht und angestoßen werden, ist schon umgestellt auf fixe Timer
• Statt GetTickCount wird PerformQueryCounter verwendet, was aber für diesen Teil keine Rolle spielt da auch 15ms vollkommen ausreichend sind. Auch das 49 Tage Problem ist in dem eigene GetTick abgefangen.
• Der USB-Sleep ist ausgeschlossen. Zum einen müsste dann ein zweiter Aufruf schneller gehen. Zum anderen tritt das Problem auch im Demo-Mode auf. Da wird gar nicht kommuniziert. Haben wir gerade erst festgestellt.
• Habe jetzt auch ein Button implementiert der einfach ein Label beschreibt. Um sicherzugehen, dass es nicht eine Funktion ist. Befehl geht zuerst in DLL und von dort per AsyncPro zuer seriellen.
• Problem wurde mittlerweile mit verschiedenen (1x Win7, 2x Win10) Rechnern nachvollzogen

[himitsu]

Erstmal fummelt die Delphi-IDE "heimlich" an den Systemtimings rum, so lange sie läuft. Da muß man manchmal bissl aufpassen.

Die Auflösung ist 15-16, Langzeit (für eine Messung/Intervall) ist sie recht stabil/zuverlässig.
Je mehr Intervalle ausgelöst wurden, summiert sich die Abweichung.



Aber um Millisekunden streitet man eh nicht, vorallem da Windows kein Echtzeitsystem ist, das Multithreading da auch noch mitspielt und es eh keine Präzisionstimer sind.

[Uwe Raabe]

Die Messdaten werden zwar in die Datenbank geschrieben, aber kann es sein, dass da noch irgendwo ein file-basiertes Logging mitläuft, bei dem die Logdatei immer erst gelesen, ergänzt und dann wieder geschrieben wird?