# Eclipse wird immer langsamer



## Guest (28. Jul 2007)

Kennt ihr auch das Problem, wenn man an grösseren Projekten arbeitet (JPA (Hibernate), Webservices, XML, merere Teilprojekte, 
Checkstyle in jedem Teilprojekt etc.) versucht Eclipse bei jedem Speichern oder auch beim Deployment auf einen Server den 
ganzen Code neu zu analysieren und auch zu compilieren?
Das geht manchmal soweit, dass man einfach nur eine einzige Zeile im Code ändert, Ctrl-S drückt, um es zu speichern
und anschliessend eine Ewigkeit warten muss, bis die IDE wieder verwendbar ist.
Es hilft wenig das automatische Compilieren zu deaktivieren. Sobald man dann auf "Projekt compilieren" im Build-Menü geht,
kann man ruhig Kaffee machen gehen, es dauert immer eine halbe Ewigkeit, bis das Sch.. Ding wieder ruhig bleibt.

Wir sind inzwischen dermassen genervt von den langen Compilierzeiten, dass wir uns ersthaft nach Alternativen umschauen.
Von einer ganzen 1-Mann-Woche geht mindestens ein halber Tag alleine für die Compilierzeiten drauf. Ich habe den Eindruck, 
dass das Problem erst mit der Einführung des in Eclipse eingebauten Compilers so ist.

Habt ihr ähnliche Erfahrungen mit Eclipse? Wie geht ihr damit um?
Ich weiss, es ist schwierig sich ein Urteil zu bilden, ohne zu wissen, wie es "bei uns" im Code aussieht, aber glaubt mir, es 
gibt keinen erkennbaren Grund, warum nach jedem Speichern das ganze Projekt erneut analysiert und teilweise neu compiliert
werden muss, nur weil man eine einzige Zeile im Code geändert hat.

Wie schaut es bei NetBeans oder RAD aus? Kann man damit arbeiten, ohne alle paar Minuten einem Progressbalken zuschauen 
zu müssen?


----------



## Guest (28. Jul 2007)

Übrigens, es geht um Eclipse 3.2.irgendwas.


----------



## mlange8801 (28. Jul 2007)

Also der Compiler von Eclipse compiliert ja eigentlich nicht alles neu sondern ersetzt ggf. die Klassen die sich geändert haben. Daher ist der eigentlich sehr performant.
Performance Probleme hatte ich eigentlich immer nur durch die Validatoren des WTP.
Die kann man aber entsprechend konfigurieren bzw. abschalten -> /properties/Validation.


----------



## Guest (29. Jul 2007)

WTP setzen wir nicht direkt ein bzw. doch, aber über das JBoss-Plugin. Die entsprechenden Validatoren sind Workspace-
weit deaktiviert. Es ist echt zum verrückt werden. Man checkt den aktuellen Code aus der Versionskontrolle aus 
(nicht innerhalb von Eclipse, sondern mit TortoiseSVN), klickt auf Refresh im Projekt und kann dann gut paar Minuten 
warten, bis das Projekt aktualisiert ist. Selbst wenn sich nur irgendeine Konfigurationsdatei geändert hat, läuft da 
irgendeine dubiose Code-Anylyse durch den gesammten Code durch (nicht Checkstyle). 
Führt man ein Ant-Script aus (z.B. für Schema-Export aus JPA), dauert es auch wieder gut 10 Sekunden, bis das
Script überhaupt startet. Noch extremer ist es, wenn dabei ein Server (JBoss) im Debug-Modus oder die Hibernate-
Console aktiv ist. Man editiert den Code irgendeiner Klasse, die nichts mit JPA zu tun hat, speichert sie und die IDE
ist für gut eine halbe Minute nicht verwendbar.
Ich habe früher mit JDeveloper von Oracle oder TCC gearbeitet und solche Probleme hat es nie gegeben. Auch 
früher mit anderen IDEs, in anderen Programmiersprachen.

Ich versuche es noch mit Eclipse-Europa-JEE. Wenn das nix wird, ist Eclipse für mich gestorben.


----------



## bronks (29. Jul 2007)

Anonymous hat gesagt.:
			
		

> WTP setzen wir nicht direkt ein bzw. doch, aber über das JBoss-Plugin ...


WTP geht mir in dieser Hinsicht auch extrem auf die Nerven. Wenn Du sowieso was für JBoss machst, dann nimm doch die JBossIDE, denn die macht so einen Mist nicht.


----------



## Wildcard (29. Jul 2007)

Anonymous hat gesagt.:
			
		

> Ich habe den Eindruck,
> dass das Problem erst mit der Einführung des in Eclipse eingebauten Compilers so ist.


Der built in Compiler wird meines Wissens nach schon seit der ersten Version ausgeliefert und ist dank der hohen Effizienz auch einer der größten Vorteile von Eclipse.
Warum ihr über Tortoise auscheckt ist mir unbegreiflich. Damit verhinderst du das inkrementell gebuildet werden kann, weil du das Eclipse Resource Management aushebelst.
Ich empfehle dir möglichst viele PlugIns zu deaktivieren und sie nach und nach wieder einzuschalten. Sobald du Performanceprobleme bekommst hast du den Schuldigen (denn ich denke das ein PlugIn verantwortlich ist).
Mylin zum Beispiel empfand ich bei großen Projekten als unbenutzbar da zu performancelastig.


----------



## Guest (29. Jul 2007)

bronks hat gesagt.:
			
		

> Anonymous hat gesagt.:
> 
> 
> 
> ...


Ja, es ist JBoss IDE - Plugin (Teil der Yoxos Distribution)


			
				Wildcard hat gesagt.:
			
		

> Anonymous hat gesagt.:
> 
> 
> 
> ...


Nein, früher konnte man den Compiler selbst bestimmen. Ich denke, es ist erst seit der Version 3.1 nicht mehr einstellbar (kann mich irren).


			
				Wildcard hat gesagt.:
			
		

> Warum ihr über Tortoise auscheckt ist mir unbegreiflich. Damit verhinderst du das inkrementell gebuildet werden kann, weil du das Eclipse Resource Management aushebelst.


Die einen im Team verwenden das eingebaute SVN-Plugin (Subclipse/JavaSVN oder sowas), die anderen, wie ich, ziehen es 
vor TortoiseSVN zu verwenden. Bei mir hat es einen simplen Grund. Der Java-Code ist nicht alles, was zum Projekt 
gehört. Da sind noch zig andere Sachen, wie ein C# Client etc. dabei. Da ich oft für das Release-Umgebung zuständig 
bin, ziehe ich es vor, alles über Tortoise zu erledigen. Diejenigen, die es über das SVN-Plugin machen, haben die gleichen 
Probleme mit den Compilierzeiten.


			
				Wildcard hat gesagt.:
			
		

> Ich empfehle dir möglichst viele PlugIns zu deaktivieren und sie nach und nach wieder einzuschalten. Sobald du Performanceprobleme bekommst hast du den Schuldigen (denn ich denke das ein PlugIn verantwortlich ist).
> Mylin zum Beispiel empfand ich bei großen Projekten als unbenutzbar da zu performancelastig.


Ich habe schon alles unnötige deaktiviert. Ich deaktiviere auch oft alle Teilprojekte, an denen ich im Moment nicht 
direkt zu schaffen habe und schliesse auch die Perspektiven, die ich momentan nicht brauche. Das Problem bleibt 
trotzdem bestehen.
Ich kann es mir einfach nicht erklären, woran es liegt. Checkstyle ist es auf keinen Fall, ich habe es auch probeweise 
deaktiviert. Mylin bzw. Mylar verwenden wird nicht. Wir haben ein etwas exotisches Bugtracking-System, welches 
davon nicht unterstützt wird. Ausserdem, wer braucht das schon. Wozu noch ein Plugin, welches man nicht dauernd 
verwendet. Das Webinterface des Bugtracking-Systems reicht uns vollkommen aus.


----------



## Wildcard (29. Jul 2007)

Ich arbeite an einem Projekt mit mehreren hundertausend Zeilen Code und kann dir versichern das es absolut kein Performanceproblem gibt. Insofern euer Projekt nicht wesentlich größer ist, würde ich den Compiler ausschließen und behaupten es *ist* ein PlugIn.


----------



## Guest (29. Jul 2007)

Wildcard hat gesagt.:
			
		

> Ich arbeite an einem Projekt mit mehreren hundertausend Zeilen Code und kann dir versichern das es absolut kein Performanceproblem gibt. Insofern euer Projekt nicht wesentlich größer ist, würde ich den Compiler ausschließen und behaupten es *ist* ein PlugIn.


Pff, nur paar hunderttausend Zeilen? 
Eigentlich habe ich nicht den Compiler selbst unter Verdacht, sondern den Build-Prozess an sich.
Ich versuche es mit einem umkonfigurierten Eclipse-Europa. Mal schauen, was daraus wird und 
ob alle nötigen Plugins damit funktionieren.


----------



## bronks (30. Jul 2007)

Anonymous hat gesagt.:
			
		

> ... Eigentlich habe ich nicht den Compiler selbst unter Verdacht, sondern den Build-Prozess an sich.
> Ich versuche es mit einem umkonfigurierten Eclipse-Europa. Mal schauen, was daraus wird und
> ob alle nötigen Plugins damit funktionieren ...


Es reicht schon eine kleine App mit 5 EJBs und einem Webinterface, damit man nach einem CTRL-S 15 Sekunden Däumchen drehen darf. Das was Du hast ist scheinbar irgendetwas, wo die JBossPlugins dabei sind, aber lad Dir mal die Komplette JBossIDE von der JBossSeite und Du wirst sehen, daß es ein ganz anderes Vergnügen ist.


----------

