Programm wird mit Laufzeit immer langsamer

[WiPhi]

Wenn du via TCP/IP direkt oder via VPN zugriff auf das System hast, wäre ggf. auch noch Remote-Debugging via PA-Server eine Möglichkeit, die Stelle zu finden, welche den Performance-Einbruch verursacht.

[himitsu]

Von AQTime ist beim Delphi eine kostenlose Edition dabei (GetIt), aber nur die etwas kränkliche IDE-Integration.

Die wichtigsten Funktionen loggen/messen kannst auch selber.
GetTickCount, TStopwatch oder Dergleichen.

Beim Befüllen von Komponenten sind so Dinge wie BeginUpdate bzw. DisableControls beachtet?

[norwegen60]

Zitat von himitsu:

Von AQTime ist beim Delphi eine kostenlose Edition dabei (GetIt), aber nur die etwas kränkliche IDE-Integration.

Die wichtigsten Funktionen loggen/nessen kannst auch selber.
GetTickCount, TStopwatch oder Dergleichen.

Beim Befüllen von Komponenten sind so Dinge wie BeginUpdate bzw. DisableControls beachtet?

Wie gesagt ist es Delphi XE. Da gabs noch kein GetIt. Ich schau mir gerade AsmProfiler und SamplingProfiler an.

BeginUpdate und DisableControls sind beachtet, sollten hier aber kaum eine Rolle spielen, da kaum Daten gemessen werden. Da gibt es andere Methoden wo alle 3 Minuten gemessen wird und das über 1.5 Tagen. Da merkt man kaum was.

[himitsu]

Damals gab es noch das "manuelle" GetIt und die Additional-DVDs

https://edn.embarcadero.com/article/41296

[TomyN]

Ich würde auf den TVirtualStringList tippen.

'Primitives' Profiling geht auch mit TimeGetTime...

[norwegen60]

Zitat von TomyN:

'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?

[Sinspin]

Zitat von norwegen60:

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.

[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?

[norwegen60]

Zitat von 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?

Ja, es werden über nlog Logs geschrieben. Das sind immer 24h Logs. Ich habe mal die Logs löschen lassen. Die beginnen dann wieder bei 0 Datensätzen. Das ändert aber nichts an dem Delay.