Java Debugmodus ist unerträglich langsam!

[LooneyLynn]

Hallo,

eins vorweg... Ich bin inzwischen in jeder Hinsicht überzeugt, dass Java von der Performance her sich nicht mehr vor C# oder C++ verstecken braucht. So viel dazu...

Mein Problem ist, dass meine Serveranwendung (eine Konsolenanwendung), unter Windows extrem langsam läuft, wenn ich sie aus einer IDE (ich nutze Netbeans 6.5) heraus starte. Dabei spielt es keine Rolle ob ich sie debugge oder einfach auf "Run" klicke. Führe ich die Anwendung hingegen über die Kommandozeile mit "java -jar ..." aus, läuft sie genauso schnell wie man es von Linux und MacOS gewohnt ist. Nur das bei den letzten beiden die Anwendung auch aus der IDE im Debugmodus so schnell läuft wie bei Windows von der Kommandozeile...

Da die Anwendung inzwischen ziemlich groß geworden ist und die Tests sehr viel Code aufrufen, ist es kein Zustand mehr... Ich muss das irgendwie hinkriegen, dass die Anwendung auch im Debugmodus unter Windows so schnell läuft wie sie es normalerweise tut! So als Richtwert würde ich sagen, dass sie MINDESTENS 10 mal langsamer in der IDE läuft... das kann echt nicht sein...!!!

Hat jemand eine Idee????

Danke im voraus... ???

 

[LooneyLynn]

Achso... Ich verwende "Windows Vista Ultimate 64-Bit" und "Java 6 Update 11", sowie "Netbeans 6.5"

 

[LooneyLynn]

Hmm da fällt mir ein, dass ja Visual Studio auch schon Probleme mit 64-Bit Debugging hatte... Liegt es vielleicht daran, dass 64-Bit Debugging unter Windows noch nicht so optimiert abläuft?? Oder vielleicht einfach ne versteckte Kommandozeilenoption die NetBeans dranhängt?! Aber ehrlichgesagt ist das für mich ein Rätzel...

 

[LooneyLynn]

Sorry, das ich noch mehr anfügen muss, aber die Erinnerungen kommen langsam wieder ;-). Ich hatte nämlich vor ein paar Jahren schonmal ein Spiel mit OpenGL in java programmiert und da war dasselbe Problem unter Windows XP 32-Bit. Also kann es daran wohl nicht liegen! Also entweder es liegt an Netbeans oder an Java selbst, dass es sich unter Windows nicht vernünftig debuggen lassen will...

 

[Murray]

Wenn die Anwendung aus Netbeans gestartet auch bei "run" so langsam ist, dann kann es wohl nicht am Debug-Modus liegen. Vielleicht ist das ein Speicherproblem: entweder arbeitet die VM am Limit und muss daher ständig den Garbage-Collector anwerfen, oder die Kombination und Anwendung und IDE und ggfs. noch zusätzlich laufenden Anwendungen benötigt mehr Speicher phsyikalisch zur Verfügung stehen, so dass das OS ständig swappen muss. Was sagt denn der Winows-Taskmanager zu Speicher- und CPU-Belastung von netbeans.exe?

 

[LooneyLynn]

Nee damit hat das definitiv nix zu tun... Ich hab 4 GB Arbeitsspeicher und nen QuadCore. Das Serverprogramm läuft nachweislich einwandfrei auch mit 100 MB Heapgröße (hab ich durch limits in der Kommandozeile getestet) so schnell wie es soll.

Das ist ein reines CPU problem. Zum Beispiel als ich gestern die AES verschlüsselung für die interne Datenbank einprogrammiert hatte, ging überhaupt nix mehr im Debugmodus. Der braucht für nen paar KBs glatte 10 Millisekunden... Das kann überhaupt nicht sein. Und unter Linux schafft der locker 100 MB pro sekunde...

Also irgendwas stimmt da fundamental nicht... Die Quadcores sind durch das Serverpogramm fast völlig ausgelastet in der IDE (beim Debuggen) wohingegen sie in der Kommandozeile so gut wie keine Auslatung zeigen, bei zehnfacher Ausführgeschwindigkeit wohlgemerkt!

 

[LooneyLynn]

Wie gesagt, was mich verwirrt ist, das es letztens (vor ein paar Jahren) schon genauso war, mit nem ganz anderen PC, Windows XP, aber auch Netbeans...

Also kann ich eigentlich nicht der einzige sein der dieses Problem hat, es sei denn Java hat mich in sein Herz geschlossen!

 

[Ariol]

Keine Ahnung woran das liegen könnte, aber klingt nach einem Problem mit Netbeans...

Hast du mal eine andere IDE getestet?
Netbeans neu installiert?

Hat Netbeans evtl ein Problem mit 64-bit?

 

[byte]

Lösung:
1.) Netbeans deinstallieren
2.) vernünftige IDE installieren (IDEA, Eclipse)
:roll:

 

[LooneyLynn]

Es geht auf 32-Bit genausowenig... Damals hatte ich noch kein 64-Bit prozessor und es war das gleiche Problem.

Nee ich hab nur Netbeans getestet. Aber ich mein das müsste dann ja irgendwo gemeldet sein, weil ich kann schlecht der einzige sein der das Problem hat nur bei Google find ich nix!

Und wenn es andere IDEs schaffen, muss Netbeans das eigentlich auch können, weil die werden immerhin direkt von Sun unterstützt!

Unter Linux und MacOS nehm ich auch Netbeans und dort gehts einwandfrei...

Kann denn jemand bestätigen, dass bei ihm unter Netbeans und Windows, der Debugmodus genauso schnell ist wie die Ausführung von der Kommandozeile (ohne IDE)??? Vielleicht mit nem kleinen Testprogram, was irgendwie ne For-Schleife abarbeitet...

 

[Gast]

:-D Verschon mich bloß mit Eclipse *Brechreiz krieg*

Aber die IDEA hatte ich schonmal probiert, das war ganz niedlich eigentlich, nur halt kostenpflichtig... Werd die gleich mal installieren und dann werden wir sehen ob es an der IDE liegt ;-)...

 

[Vayu]

du hast nicht zufällig unter Windows noch irgendwo n bedingten breakpoint gesetzt, den du unter Linux nicht hast?

weil das macht das debuggen richtig übelst langsam.

 

[LooneyLynn]

@Vayu:

Wie meinst du das? Natürlich ist das Programm übersäht mit Breakpoints... Also solche die man an der Seite anklicken kann... Aber die werden in der Regel nich angesprungen, weil die meistens nur Fehler melden...

Und unter Linux hab ich die ja auch alle... Und dort geht es trotzdem so schnell...

Oder geht es nur unter Windoof deswegen so langsam?

 

[Vayu]

mit bedingten breakpoints meine ich solche, die nur angesprungen werden, wenn eine bestimmte vordefinierte bedingung gegeben ist.

unter eclipse kann man zum beispiel sagen

"Du Breakpoint hältst nur an wenn x > 0"

und solche dinger machen die programmausführung extremst langsam.

was das OS angeht, kA ich arbeite nur unter windows

 

[LooneyLynn]

Nee solche breakpoints hab ich nicht...

Allerdings ist mir trotzdem unklar wieso es dadurch langsamer gehen soll... Ist doch nur ne If-Anweisung mit nem "INT 3" im codepfad...

Gut aber ich probier grad das projekt mit IDEA zum laufen zu bekommen... dann kann ich vielleicht mehr sagen...

 

[byte]

"Du Breakpoint hältst nur an wenn x > 0"

und solche dinger machen die programmausführung extremst langsam.

Kann ich nicht bestätigen. Sind bei mir nicht merkbar langsamer als normale Line Breakpoints.

Was die Anwendung beim Debuggen grundsätzlich ausbremst, sind Method Breakpoints. Man sollte stattdessen immer Line Breakpoints benutzen!

 

[Vayu]

"Du Breakpoint hältst nur an wenn x > 0"

und solche dinger machen die programmausführung extremst langsam.

Kann ich nicht bestätigen. Sind bei mir nicht merkbar langsamer als normale Line Breakpoints.

Was die Anwendung beim Debuggen grundsätzlich ausbremst, sind Method Breakpoints. Man sollte stattdessen immer Line Breakpoints benutzen!

sind alles Erfahrungswerte Methodenbreakpoints sind bei mir wiederum nicht wirklich langsamer

 

[byte]

Kommt beim Conditional Breakpoint halt drauf an, was Du da prüfst. Wenn Du irgendwelchen teuren String-Vergleiche machst und die dann 1000 mal aufgerufen werden, dann wirds natürlich langsamer.

 

[LooneyLynn]

Seltsam...

Unter IntelliJ IDEA 8.0 scheint es zu funzen...

Dann müssen die bei NetBeans ja irgendwas falsch gemacht haben!

 

[LooneyLynn]

Die IDEA ist ja auch sonst viel schneller als netBeans... *denk* Schon beim Step-By-Step debugging... da ist irgendwie ein unterschied wie tag und nacht... :-D

 

[byte]

Jo, sag ich doch:

Lösung:
1.) Netbeans deinstallieren
2.) vernünftige IDE installieren (IDEA, Eclipse)
:roll:

 

[Wildcard]

Kommt beim Conditional Breakpoint halt drauf an, was Du da prüfst. Wenn Du irgendwelchen teuren String-Vergleiche machst und die dann 1000 mal aufgerufen werden, dann wirds natürlich langsamer.

Bei mir sind Conditional Breakpoints auch bei einfachen Prüfung langsam (unter der Vorraussetzung das die Code Stelle häufig durchlaufen wird).

 

[Ebenius]

Kommt beim Conditional Breakpoint halt drauf an, was Du da prüfst. Wenn Du irgendwelchen teuren String-Vergleiche machst und die dann 1000 mal aufgerufen werden, dann wirds natürlich langsamer.

Bei mir sind Conditional Breakpoints auch bei einfachen Prüfung langsam (unter der Vorraussetzung das die Code Stelle häufig durchlaufen wird).

Dem stimme ich zu. Das Teuere am Breakpoint ist doch das Suspend der VM. Und das muss gemacht werden, bevor die Bedingung geprüft wird. Die Komplexität der Bedingung ist quasi irrelevant.

 

[Vayu]

ich setze conditional bps eh nur ein wenn es ne stelle ist, die sehr oft durchlaufen wird ^^ weil wenn da nur ab und zu wer durchkommt, dann braucht man auch keinen conditional

 

[Gast]

Hmm der Sinn von so einem conditional breakpoint erschließt sich mir trotzdem nicht. Obwohl ich nicht wusste das es das überhaupt gibt, hab ich auch in meinem ganzen leben noch nie intuitiv gesagt "wenn man doch bloß dem breakpoint noch ne bedingung zuweisen könnte"...

aber egal...

Zurück zur NetBeans IDE; ich bleibt bei der, die gefällt mir am besten! Und das lustige ist, seitdem ich IDEA installiert hab, läuft NetBeans auch so schnell wie auf Linux.. Jetzt kapier ich gar nix mehr. Vielleicht weil es nicht wollte, das es durch IDEA ersetzt wird keine Ahnung!

 

[Ebenius]

Hmm der Sinn von so einem conditional breakpoint erschließt sich mir trotzdem nicht. Obwohl ich nicht wusste das es das überhaupt gibt, hab ich auch in meinem ganzen leben noch nie intuitiv gesagt "wenn man doch bloß dem breakpoint noch ne bedingung zuweisen könnte"...

Das kann ziemlich schnell sinnvoll werden. Zum Beispiel, wenn Du einen Fehler hast, der immer in einer Methode auftritt, wenn Du einen bestimmten Wert übergibst (zum Beispiel jeden String der länger ist als 12 Zeichen). Wenn nun diese Methode sehr oft aufgerufen wird (meistens mit Strings die kürzer sind als 12 Zeichen), dann wird es zur Qual immer wieder "run" zu klicken, bis mal der Eingabewert im 25ten Lauf die Fehlerbedingung erfüllt. Dabei sind bedingungte Breakpoints ein echter Vorteil.

Ebenius

 

[LooneyLynn]

Oh... naja da hab ich dann einfach ne if anweisung vor den breakpoint geschrieben *denk*... na gut dann hab ich die wohl doch verwendet... aber das mit der if anweisung ist dann wohl anscheinend wesentlich schneller... :-D

 

[Ebenius]

Oh... naja da hab ich dann einfach ne if anweisung vor den breakpoint geschrieben *denk*... na gut dann hab ich die wohl doch verwendet... aber das mit der if anweisung ist dann wohl anscheinend wesentlich schneller... :-D

Das stimmt. Aber was machst Du, wenn der Fehler in einer Bibliothek passiert die Du nicht verändern kannst?

 

[LooneyLynn]

Einen Bug melden ;-)...

 

[Ebenius]

Einen Bug melden ;-)...

Es muss ja nicht der Code schuld sein, in dem der Fehler auftritt.

 

[Wildcard]

Oh... naja da hab ich dann einfach ne if anweisung vor den breakpoint geschrieben *denk*... na gut dann hab ich die wohl doch verwendet... aber das mit der if anweisung ist dann wohl anscheinend wesentlich schneller... :-D

Die Conditional Breakpoints sind da IMO eleganter. Du brauchst keinen Code zu ändern und musst daher hinterher auch keine Debug Artefakte rauswerfen.