alias5000 - Sa 21.06.08 22:17
Titel: Debugger ist extrem langsam, bei eigener Multithreading EXE

---

Hallo zusammen,
ich bin im Moment mittelschwer genervt, weil ich auf meinem Laptop mein Projekt nicht wirklich weiterentwickeln kann.

Der Laptop ist Rechner mit Vista Home Premium drauf, Delphi ist so installiert, dass es auch Admin-Rechte funktioniert (Delphi mit den Rechten auszuführen hilft leider nicht weiter).

Mein Problem ist folgendes:
Ich entwickle derzeit eine Anwendung, bei der ich mehrere TIdTCPClient Instanzen in einem eigenen Thread laufen lasse, sowie ein TIdTCPServer im Main-Thread verwende. Die Anwendung arbeitet mit Laufzeitpackages (BPLs). Seitdem ich das Package, dass diese Threads und den TCPServer beinhaltet zur Anwendung hinzugefügt habe, dauern alle Aktionen der Anwendung extrem viel länger (Faktor 5-15 geschätzt), wenn die Anwendung im Delphi-Debugger läuft. Wenn sie dies nicht tut, ist sie so schnell, wie vorher, also ganz normal.
Ich glaube nicht so richtig daran, dass es die Ausführung der Threads ist, denn diese werden erst später im Programmablauf gestartet (und die Indy 9 Komponenten auf aktive := true geschaltet). Aber das Programm stockt ab der ersten Sekunde.
Vielleicht hat das etwas mit den Packages zu tun, die dazu noch mit in die Anwendung geholt werden. Dies ist eigentlich nur die indy.dcp

Was nicht verwunderlich, aber erwähnenswert ist, ist folgendes:
Delphi läuft immer, wenn das Programm viel Rechenleistung benötigt mit einer sehr starken Auslastung, die sich erst wieder leg, wenn das Programm auch nichts zu rechnen hat. An sich ja nachvollziehbar, es läuft ja der Debugger mit. Aber die Ausmaße sind schon ziemlich erschreckend.

Wenn ich im per Einzelschritt debugge, dann dauert eine Einfache Anweisung, alla 1+1 schon gut eine halbe bis ganze Sekunde :(

Auf meinem XP-Rechner ist dies nicht der Fall und auch auf einem anderen Windows Vista (Home Premium?) Rechner ist dies nicht der Fall.
Welche Faktoren könnten dieses Verhalten beeinflussen?



Probiert habe ich auch, das eingesetzte DelphiSpeedUp zu deinstallieren. Das halt leider nichts gebracht.
Updates und Hotfixes habe ich m.W. nach alle installiert.

Die Alternativlösung habe ich auch schon umgesetzt, das ist ein virtueller PC mit einem anderen Betriebssystem. Allerdings habe ich nur einen 1,6 GHz Dual Core Rechner ohne Hardware-Virtualisierung. Microsoft Virtual PC 2007 nutzt nur eine CPU Core und somit habe ich dann auf einmal einen virtuellen 1,6 GHz Rechner, mit einem Wirt-OS Windows Vista.
Das ist alles andere als Performant :?

Wo zum Teufel könnten Anregungen und Ansätze für eine Lösung für das Problem stecken?

Viele Grüße
alias5000

arj - So 22.06.08 11:11

---

Ich hab zwar keine Lösung für den Debugger, aber
vielleicht kannst du das Problem umgehen indem du einfach viel auf
die Konsole rausschreibst?
Das ist bei Multithreading Applikationen manchmal sogar übersichtlicher.

alias5000 - So 22.06.08 11:17

---

Naja, aber schneller wird die Anwendung dadurch dann aber auch nicht, oder?
Das Problem ist nicht, dass ich in diesem Modul jetzt Fehler suche, sondern dass die ganze Anwendung auf diesem Modul später aufbauen wird und ich in anderen Bereichen der Anwendung im Moment arbeite. Aber wenn die ganze Anwendung so langsam ist, kann ich da nicht richtig debuggen

arj - So 22.06.08 11:28

---

Wenn du das ganze direkt ausführst und Infos auf die Konsole
schreibst, dann musst du ja nicht im Debugging Modus starten.
Und dann läuft die Anwendung ja, so wie du schreibst, schnell.

alias5000 - So 22.06.08 11:50

---

Ach so meinst du das.

Das ist theoretisch tatsächlich eine Möglichkeit.
Allerdings schätze ich die Möglichkeiten des Debuggers inzwischen sehr und möchte nur wegen einem von zwei Rechnern nicht darauf verzichten. Bisher konnte ich immer auf meinen zweiten Rechner ausweichen, was jetzt leider nicht möglich ist.

Chemiker - Sa 01.11.08 00:53

---

Hallo alias5000,

der Beitrag ist ja schon was älter, aber ich stand vor dem gleichen Problem und habe beim Suchen nach einer Lösung auch diesem Beitrag angeboten bekommen.

Bei mir lag es daran, dass unter Optionen\Debugger-Optionen\Ereignisprotokoll unter Meldungen die Meldung: Windows-Meldungen mit einem Hacken versehen war.

Bis bald Chemiker

BenBE - Sa 01.11.08 01:29

---

Ein anderer Punkt, der zu diesem Verhalten führen kann, ist, wenn Haltepunkte mit Break-Condition gesetzt sind.