Programm wird mit Laufzeit immer langsamer

[norwegen60]

Zitat von Der schöne Günther:

Einen "Profiler" verwenden, denn genau dafür wurden die erfunden. Gib einfach mal "Delphi Profiler" in die Suchmaschine deines Vertrauens ein, es gibt auch mehrere kostenlose Lösungen.

Ich benutze hin und wieder den MsSQL-Profiler. Habe aber nicht realisiert, dass es sowas "natürlich" auch für die Delphi-Seite gibt.

Danke

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

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