Wie spühre ich unsichtbare Programmfehler auf?

[daredd]

Hallo Freunde,

ich habe ein Programm, das in Delphi geschrieben wurde. Es arbeitet zusammen mit einer Datenbank (GDB auf Firebird Server mit BDE).

Nun ist es so das es nach einer gewissen Zeit einfach nur hängen bleibt, bzw. sehr langsam läuft.
Ich vermute es liegt an der BDE oder an der Datenbank an sich, je mehr Daten in der Datenbank gespeichert sind, desto langsamer wird das Programm mit der Zeit.


Kann mir einer von euch ein tipp geben? Gibt es irgendein Tool womit ich das Programm durchlaufen lassen kann um evtl. Fehlerstellen zu finden?

[omata]

Benutze FastMM, um das Programm auf Speicherlecks zu überprüfen.

[daredd]

Ah, stimmt! Davon habe ich schon mal gehört.

Kannst du mir sagen wo ich es her bekomme? Das muss man doch irgendwie ins Delphi-Projekt mit einbinden oder?

[himitsu]

Welche Delphi-Version hast du denn?

In neueren Delphis ist ja eine nicht ganz atuelle und wohl etwas abgespeckte Version davon enthalten.
(der alte schlechtere Delphi-MemoryManager wurde mal dadurch ersetezt)

ansonsten FastMM (man mag's kaum glauben ... gleich ganz oben zu finden )

[Elvis]

Benenne die DB unbedingt um!
GDB ist eine magische Endung, die seit XP für irgendwelche Sicherungsdienste benutzt wird.
Windows wird dich so schnell ausbremsen, dass es nicht mehr lustig ist.

Ansonsten, falls es das nicht war, gibt es IMO keine richtigen, automatischen Sampling und Profiling tools für Delphi.
AQTime kommt aber nahe ran (ist aber ewig her als ich es das letzte Mal angefasst habe).
Du willst ja genau wissen was langsam wird und dich darauf konzentrieren, anstatt die ganze App zu kaputtoptimieren.

[alzaimar]

Die Aussage 'es wird immer langsamer' ist reichlich unpräzise.
Was wird langsamer? Wo? Welche Aktion ist betroffen?

Präzisiere dein Problem, analyisere es und kreise es ein. Programme sind immer noch deterministisch, sodaß man so eine Performancebremse relativ schnell durch Eingrenzung finden kann.

[daredd]

Gut, danke Leute.
Ich werde das mal ausprobieren.

@ Elvis:

Wie meinst du das mit Datenbank umbennen? Die Endung .gdb kann ich doch nicht einfach so weg nehmen?

[Elvis]

Zitat von daredd:

Gut, danke Leute.
Ich werde das mal ausprobieren.
@ Elvis:
Wie meinst du das mit Datenbank umbennen? Die Endung .gdb kann ich doch nicht einfach so weg nehmen?

Warum denn nicht?
Dateiendungen sind doch eigentlich nur nur ein Relikt aus der DOS-Ära und eigentlich relativ belanglos.
Nunja, außer wenn sie .GDB heißt, dann wird Windows nämlich irgendwelchen Käse bei allen Änderungen verzapfen.
Wenn ich mich recht entsinne waren es ständige Shadow copies, weiß es aber nicht genau.
Ist auch nicht wichtig. Ändere sie ASAP zu irgendwas != GDB. Das kann fdb sein, das kann auch .HeinzAugustFerdinandOlafDB sein.
Das ist ein Problem, welches seit 2002 eigentlich immer und überall und in jeder Readme ud FAQ zu finden sein sollte, die auch nur weitläufig etwas mit Interbase oder Firebird zu tun hat, mehrfach und ausführlich beschrieben sein sollte.

[Blup]

Falls das Programm nach einem Neustart wieder schneller läuft, kommt als Ursache eine Transaktion in Frage, die nicht beendet wird.
Wenn es sich um die Transaktion handelt, in der die Daten eingefügt werden, einfach Commit zwischendurch aufrufen.
Es könnte sich aber um eine andere Transaktion handeln(z.B. für irgendwelche datensensitive Steuerelemente zur Anzeige).
Da sich der Server jeden Zustand der Daten seit dem Start der ältesten Transaktion merken muss, sollten auch solche Transaktionen regelmäßig geschlossen und neu geöffnet werden.

Das Problem mit der GDB-Dateiendung tritt nur beim Öffnen solcher Dateien auf. Windows erstellt dann je nach Konfiguration eine Kopie der Datenbank. Viel gefährlicher ist in diesem Zusammenhang, daß die aktuelle Datenbank z.B. bei einer Systemwiederherstellung automatisch durch eine ältere Version ersetzt werden könnte.

[daredd]

Vielen Dank Blup! Und cooler Nickname