La scheda di commutazione di Eclipse 3.5 (e più recente) è molto lenta

Question

Sto usando eclipse 3.5 (build di cacao) su Macos 10.5 con Java 1.5.0.19.

Ho solo 3 file java aperti 1 file ~ 2000 righe le altre 2 sono ~ 700 righe.

Ma quando passo da una scheda di file a un'altra, eclipse impiega molto tempo (~ 20 secondi) per passare a un'altra scheda.

ho già cambiare l'eclipse.ini a

more eclipse.ini 
-startup 
../../../plugins/org.eclipse.equinox.launcher_1.0.200.v20090520.jar 
--launcher.library 
../../../plugins/org.eclipse.equinox.launcher.cocoa.macosx_1.0.0.v20090519 
-product 
org.eclipse.epp.package.jee.product 
-showsplash 
org.eclipse.platform 
--launcher.XXMaxPermSize 
256m 
-vmargs 
-Dosgi.requiredJavaVersion=1.5 
-XstartOnFirstThread 
-Dorg.eclipse.swt.internal.carbon.smallFonts 
-XX:MaxPermSize=512m 
-Xms128m 
-Xmx1024m 
-Xdock:icon=../Resources/Eclipse.icns 
-XstartOnFirstThread 
-Dorg.eclipse.swt.internal.carbon.smallFonts 

C'è un modo per rendere più veloce Eclipse 3.5?

Grazie.

Answer 1

sono passato questa riga nel file eclipse.ini (trovato all'interno del pacchetto di applicazione eclisse):

-Dosgi.requiredJavaVersion=1.5 

a

-Dosgi.requiredJavaVersion=1.6 

e commutazione scheda era ancora veloce.

Answer 2

Questo è un problema noto. Poiché si utilizza JDK1.5, è possibile provare la variante Carbon.

Answer 3

Vai con il rilascio Cocoa a 32 bit. Il 64-bit non aiuterà IMHO. Funziona davvero alla grande sul mio MBP a 2,4 GHz. Di solito ho circa 30 file aperti, alcuni abbastanza grandi, mai sperimentato quello che descrivi.

Cerca di ottenere una nuova distro Cocoa a 32 bit plain-vanilla, non modificare nulla e controlla se c'è un problema. Potrebbe anche essere un plugin canaglia. Avete installato?

Controlla lo stato dell'heap. Apri le preferenze di Eclipse, nella prima pagina delle preferenze c'è un'opzione "Mostra stato heap". Potresti essere a corto di memoria. Controlla lo stato di swap della tua macchina usando il monitor delle attività: se scambia molto, ti consiglio di chiudere altre applicazioni. In generale, raccomando 4 GB di RAM per le macchine di sviluppo.

Answer 4

Questo potrebbe essere il bug a cui è stato fatto riferimento. https://bugs.eclipse.org/bugs/show_bug.cgi?id=282229

Answer 5

Ho riscontrato lo stesso problema utilizzando OS X 10.5.7 ed Eclipse 3.5.2 su una macchina di fascia bassa (iMac del primo 2006 con 1,5 GB). Subito dopo aver avviato la mia macchina, tuttavia, tutto è davvero scattante. Posso persino avviare JBoss AS e non c'è ancora alcun rallentamento. Monitoro "Swap used" nel monitoraggio dell'attività e rimane a 0 byte usati.

Quindi, lancio qualcos'altro, come iTunes e mail o passando a un altro account.

Le cose diventano lente allora, il che è previsto, e vedo "Swap used" in aumento. Eclipse rallenta a passo d'uomo e lavorare con esso è quasi impossibile.

Poi ho disconnesso l'altro account, chiudere tutte le altre app che ho aperto, quindi lo stato della mia macchina è fondamentalmente lo stesso di quando era ancora veloce. MA ... rimane cane lento! Anche se ho chiuso tutte le altre app, "Swap used" nel monitor delle attività diminuisce leggermente (da ~ 1,2 GB a ~ 700 MB). Basta passare da una scheda all'altra tra due semplicissimi file Java che impiegano fino a 20 secondi, nel frattempo vedo nel monitor dell'attività che l'utilizzo della CPU sale al 100%.

Qui c'è sicuramente qualcosa di strano. Questo non sembra un comportamento normale. È come se Mac OS X entri in una "modalità lenta" quando richiedo troppe risorse da esso, ma quando le risorse ci sono ancora non riesce a recuperare.

Molto fastidioso!

Se reimposta la macchina e apro di nuovo lo stesso identico working set (Eclipse con gli stessi 2 file aperti, JBoss AS è avviato in modalità di debug, Safari con 1 finestra) tutto è davvero molto veloce.

Answer 6

passare a 1.6 aiuta davvero. Questo è il link per individuare il file eclipse.ini per Mac http://wiki.eclipse.org/Eclipse.ini

Answer 7

ora posso più o meno confermare che il problema è davvero con Eclipse 3.5.

Ho eseguito Eclipse su una molto più potente Mac, un 27" Core i7, 2,93 GHz con 8 GB di RAM e uno SSD con OS X 10.6.4. Inizialmente questo era estremamente liscia e scattante, ma dopo un Tempo di una decina di ore circa, Eclipse improvvisamente ha iniziato a rallentare di nuovo: avevo poco o quasi nulla in esecuzione in background: solo Eclipse (32 bit, dato memoria da 1,5 GB), JBoss AS e Safari.

Un semplice interruttore di tabulazione richiederebbe alcuni secondi e nel frattempo ho notato che il carico della CPU su un core andava al 100%. Lo stesso è accaduto con le prospettive di commutazione e varie altre operazioni

Quando risiedo tartare solo Eclipse, tutto era di nuovo completamente veloce. Questo è successo un paio di volte.

Answer 8

Questa segnalazione di bug di eclissi è azzeccata con il comportamento che descrivi. (Ho avuto la stessa esperienza con una nuova installazione su una macchina Juno muscoloso XP.)

https://bugs.eclipse.org/bugs/show_bug.cgi?id=385272

La parte più utile del bug report era in comment 29, che suggerisce la creazione di una nuova area di lavoro. Il modo più semplice per farlo è:

1) uscita eclissare

2) rinomina .../path/to/lavoro/.metadata/.plugins/org.eclipse.e4.workbench/banco da lavoro .xmi (ad esempio, aggiungere "old")

3) iniziare eclisse

Credo che cambiando -Dosgi.requiredJavaVersion = 1,5 ÷ 1,6 può aiutare solo incidentalmente, se non del tutto.

Answer 9

Aumentare i limiti di memoria in eclissi.ini sembra aver risolto questo per me - non è sicuro se rimane fissa anche se

DA:

-vmargs 
-Xms40m 
-Xmx512m 

PER

-vmargs 
-XX:MaxPermSize=512m 
-Xms256m 
-Xmx784m 

Inoltre - se siete venuti da aptana3 e ha importato il tuo progetto - Devi farlo

1. Fare clic su Proprietà progetto
2. Vai a "Costruttori"
3. Assicurarsi che non ci sono "Costruttori mancanti" Se ci sono, li deselezionare - ho avuto due rimasto da Aptana quando ho importato il mio progetto (com.aptana.ide. core.unifiedBuilder E com.aptana.editor.php.aptanaPhpBuilder)

---- ---- UPDATE

problema è stato risolto - , ma non per le ragioni che ho pensato. Il mio SVN non era più riconosciuto da Eclipse. Non appena ho premuto "condividi con la squadra" e ricollegato, i problemi di commutazione delle schede sono ricomparsi. Ho intenzione di provare a capire se si tratta di un problema svnKit vs JavaHL - Non sono sicuro di quale connettore ho scelto quando ho configurato eclipse questa volta.

Se si vuole confermare questo è il problema cercando di scollegare dalla (disconnessione Team->) SVN e riavviare Eclipse

Answer 10

So che questo è un po 'tardi al gioco, ma ho trovato che la modifica delle autorizzazioni per ~ workspace.metadata.plugins \ org.eclipse.e4.workbench per negare a me stesso l'accesso interrotto il problema di rallentamento.

Sembra che Eclipse (4.2.0) scriva un file di impostazioni corrotto ogni tanto, e quando viene caricato all'avvio nuovamente rallenta tutto in quanto genera costantemente errori interni. Cambiare la sicurezza su quella directory in modo che Eclipse non possa scrivere su di essa è una sorta di "correzione"! Significa che ogni volta che viene avviato Eclipse torna alle impostazioni predefinite, ma se la velocità è più importante, penso che sia un sacrificio utile.

Answer 11

Ora ci sono patch per Juno per iniziare a risolvere questo problema. Vedere comment #212 on bug 385272 per informazioni su come aggiornare l'installazione. Se aspetti ancora un po 'di tempo, dovresti trovare queste correzioni nella milestone di Kepler il 21/12/2012.

(credo che gli altri suggerimenti pubblicati qui, ad esempio, l'aumento di memoria o tweeking vari params di avvio o preferenze potrebbe avere qualche effetto positivo sulle prestazioni, ma il problema di fondo è discussioni impazzite come descritto nel bug report.)

Answer 12

Per me il problema era l'integrazione della connessione SVNKit con la versione Juno di Eclipse. Sto facendo di sviluppo Android utilizzando la versione di Eclipse Juno e quando ho acceso il team di integrazione svnkit ho ottenuto le seguenti problemi descritti:

1. Molto lento passaggio tra file di codice in Eclipse IDE.
2. Spazio e spazio extra nella barra degli strumenti tra le icone di stampa e Android SDK Manager.

Per me ...Ho disattivato le seguenti impostazioni sotto Finestra-> Preferenze-> Team-> SVN sotto Impostazioni vista ... c'era un'impostazione per "Mostra sincronizzare le informazioni in modo incrementale" ... L'ho disattivato e il passaggio tra i file è migliorato .. .. ma c'è ancora un ritardo rispetto a NON avere SVN connesso.

Senza SVN connesso ... la commutazione tra file è normale.

Avevo Java 1.6 in Eclipse.ini Non ho modificato le impostazioni per la memoria.

Answer 13

TL; DR per il filo bug:

http://wiki.eclipse.org/Platform_UI/Juno_Performance_Investigation#Resolution

lavorato per me.

Answer 14

Il problema originale di rallentare il passaggio da una scheda all'altra è riapparso in Eclipse Neon (solo 4.6.2?) Utilizzando il tema scuro.

Soluzione: disattivare le barre di scorrimento a tema a e4-dark_win.css (fondo del file): StyledText { swt-scrollbar-themed: false; [...]