Perché IntelliJ 13 IDEA è così lento dopo l'aggiornamento dalla versione 12?

Durante l'utilizzo di IntelliJ 13 ultimate edition per una settimana, sembra davvero molto lento.

Prima di tutto, l'intero IDE si ferma per circa un secondo ogni tanto. Il completamento automatico dell'editor Java è molto lento rispetto alla versione 12.

Non ho modificato nulla rispetto alle impostazioni predefinite se non l'utilizzo di un tema Dracula.

Sembra che questo non sia un mio problema. Molte persone hanno suggerito di impostare una dimensione dell'heap superiore a quella predefinita o di svuotare la cache, ma non ho verificato o verificato questi suggerimenti. Devo modificare alcune impostazioni per migliorare le prestazioni della nuova versione?

Ho avuto lo stesso problema con lentezza in IntelliJ 13 dopo l'aggiornamento da 12. Quello che ha funzionato per me è stato modificare le idee64.vmoptions nella cartella bin e impostare l'heap massimo su 8 GB (era 512 MB) e il Max PermGen su almeno 1 GB (era 300 MB). Esempio sotto:

-Xms128m
-Xmx8192m
-XX:MaxPermSize=1024m

Al riavvio è stato molto più veloce.

Per IntelliJ 2020 che risale al 2017 su Mac /Applications/IntelliJ IDEA.app/Contents/bin/idea.vmoptions

Su un Mac, questo file si trova in questo percorso:

Per IntelliJ 14 o 15 su Mac /Applications/IntelliJ IDEA 14.app/Contents/bin/idea.vmoptions

Per IntelliJ 13 su Mac /Users/yourusername/Library/Preferences/IntelliJIdea13/idea.vmoptions

Il programma di aggiornamento di IntelliJ (dal 2017) sembra ripristinare questa modifica, quindi potrebbe essere necessario applicarla nuovamente dopo l'aggiornamento.

Su Ubuntu Linux, questo file si trova in questo percorso rispetto alla directory di installazione:

idea-IU-135.475/bin/idea64.vmoptions

e per il 2016.2:

 ~/.IdeaIC2016.2/idea64.vmoptions

Su Windows 10 (edizione della community mostrata qui) questi file si trovano in:

C:\Program Files (x86)\JetBrains\IntelliJ IDEA Community Edition 2016.1.3\bin\idea64.exe.vmoptions

Ho notato che la disabilitazione di molti plug-in aiuta davvero ad accelerare IntelliJ. Ad esempio, non sto sviluppando applicazioni Android. La disattivazione dei plug-in correlati allo sviluppo di Android velocizza i tempi di caricamento e rende il programma molto più fluido sulla mia macchina.

Nel mio caso, l'integrazione con GIT sembra causare un rallentamento frustrante dell'editor con 13.

Durante la digitazione, anche i commenti, con l'integrazione GIT attivata, dopo circa 30 caratteri, l'interfaccia utente si blocca per circa un secondo. Di solito non è lungo, ma molto fastidioso.

Sto usando GIT 1.7.8.0. In esecuzione su Windows 7 64 con un'unità a stato solido e 12 concerti di ram e Intel I7 con 8 CPU. Ho provato varie cose, come l'aggiornamento di idea64.exe.vmoptions per utilizzare più memoria, come -Xmx2400m e -XX: MaxPermSize = 2400m, -XX: ParallelGCThreads = 6, ma non ha risolto il problema.

Il repository git è di 1.3 concerti con 65.000 file.

Ho creato un nuovo progetto "grails" in un nuovo repository git e non ci sono problemi. Ho creato un nuovo progetto grails nel repository git di grandi dimensioni esistente e intellij è lento. Ho disattivato l'integrazione git aprendo la finestra di dialogo delle impostazioni del progetto ed eliminando la radice git e il problema scompare.

Ho provato a disabilitare tutte le operazioni in background di GIT attraverso l'interfaccia utente 13, ma non ha fatto differenza. Ho anche provato sia la modalità GIT integrata che la modalità nativa e non ha fatto alcuna differenza.

Nel mio caso, la soluzione sembra essere quella di disabilitare l'integrazione di GIT fino a quando non ne ho bisogno e quindi aggiungere nuovamente la radice git. Se qualcun altro può verificare lo stesso problema, potremmo segnalarlo come un problema.

Nel mio caso, IntelliJ ha involontariamente ridotto il degrado delle prestazioni utilizzando JDK / JRE 1.8. Ciò sembra influire negativamente sulle prestazioni di rendering e porta anche a crash e deadlock imprevisti.

Ciò renderebbe inutilizzabile l'IDE (latenza di 1-2 secondi sulle operazioni) anche per un piccolo progetto ~ 3KLOC.

Assicurati di utilizzare JDK / JRE 1.7 quando esegui intellij:

JAVA_HOME=/usr/lib/jvm/jdk1.7.0_67 intellij

(o qualunque sia l'equivalente per il tuo sistema operativo)

È possibile controllare il JRE utilizzato per eseguire intellij in Guida -> Informazioni -> JRE.

Beh, non posso rispondere al post di Engineer Dollery sopra perché non ho ancora 50 rappresentanti ... ma ho notato la stessa cosa. È già stato segnalato un problema relativo a hg4idea: http://youtrack.jetbrains.com/issue/IDEA-118529 .

Non ci sono ancora correzioni se non per disabilitare il plugin hg4idea. Ma se questo risulta essere il tuo problema, vota per il bug!

Modifica: JetBrains ha corretto l'errore nella build IU-138-815!

Ho avuto un problema simile. In quel caso era il plug-in Subversion. (Mac Mavericks, versione SVN 1.7.10) Una volta disabilitato questo IntelliJ è diventato di nuovo utilizzabile.

Capito da jstack:

"Change List Updater" daemon prio=2 tid=10df3f000 nid=0x12a421000 runnable [12a41f000]
   java.lang.Thread.State: RUNNABLE
    at java.util.Collections.unmodifiableList(Collections.java:1131)
    at com.intellij.execution.configurations.ParametersList.getList(ParametersList.java:88)
    at com.intellij.execution.configurations.GeneralCommandLine.getCommandLineString(GeneralCommandLine.java:210)
    at com.intellij.execution.configurations.GeneralCommandLine.getCommandLineString(GeneralCommandLine.java:189)
    at org.jetbrains.idea.svn.commandLine.CommandExecutor.createProcessHandler(CommandExecutor.java:186)
    at org.jetbrains.idea.svn.commandLine.CommandExecutor.start(CommandExecutor.java:137)
    - locked <76afcdfb8> (a java.lang.Object)
    at org.jetbrains.idea.svn.commandLine.CommandExecutor.run(CommandExecutor.java:262)
    at org.jetbrains.idea.svn.commandLine.CommandRuntime.runWithAuthenticationAttempt(CommandRuntime.java:62)
    at org.jetbrains.idea.svn.commandLine.CommandUtil.execute(CommandUtil.java:206)
    at org.jetbrains.idea.svn.commandLine.CommandUtil.execute(CommandUtil.java:189)
    at org.jetbrains.idea.svn.commandLine.SvnCommandLineInfoClient.execute(SvnCommandLineInfoClient.java:120)
    at org.jetbrains.idea.svn.commandLine.SvnCommandLineInfoClient.issueCommand(SvnCommandLineInfoClient.java:104)
    at org.jetbrains.idea.svn.commandLine.SvnCommandLineInfoClient.doInfo(SvnCommandLineInfoClient.java:90)
    at org.jetbrains.idea.svn.commandLine.SvnCommandLineInfoClient.doInfo(SvnCommandLineInfoClient.java:232)
    at org.jetbrains.idea.svn.commandLine.SvnCommandLineStatusClient.doStatus(SvnCommandLineStatusClient.java:106)
    at org.jetbrains.idea.svn.SvnRecursiveStatusWalker.go(SvnRecursiveStatusWalker.java:79)
    at org.jetbrains.idea.svn.SvnChangeProvider.getChanges(SvnChangeProvider.java:89)
    at com.intellij.openapi.vcs.changes.ChangeListManagerImpl.a(ChangeListManagerImpl.java:686)
    at com.intellij.openapi.vcs.changes.ChangeListManagerImpl.a(ChangeListManagerImpl.java:596)
    at com.intellij.openapi.vcs.changes.ChangeListManagerImpl.d(ChangeListManagerImpl.java:480)
    at com.intellij.openapi.vcs.changes.ChangeListManagerImpl.access$1100(ChangeListManagerImpl.java:71)
    at com.intellij.openapi.vcs.changes.ChangeListManagerImpl$ActualUpdater.run(ChangeListManagerImpl.java:387)
    at com.intellij.openapi.vcs.changes.UpdateRequestsQueue$MyRunnable.run(UpdateRequestsQueue.java:260)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
    at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
    at java.util.concurrent.FutureTask.run(FutureTask.java:138)
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
    at java.lang.Thread.run(Thread.java:695)

altra corsa:

"Change List Updater" daemon prio=2 tid=124556000 nid=0x129c7a000 runnable [129c78000]
   java.lang.Thread.State: RUNNABLE
    at java.io.UnixFileSystem.getBooleanAttributes0(Native Method)
    at java.io.UnixFileSystem.getBooleanAttributes(UnixFileSystem.java:228)
    at java.io.File.exists(File.java:733)
    at org.apache.xerces.parsers.SecuritySupport$7.run(Unknown Source)
    at java.security.AccessController.doPrivileged(Native Method)
    at org.apache.xerces.parsers.SecuritySupport.getFileExists(Unknown Source)
    at org.apache.xerces.parsers.ObjectFactory.createObject(Unknown Source)
    at org.apache.xerces.parsers.ObjectFactory.createObject(Unknown Source)
    at org.apache.xerces.parsers.SAXParser.<init>(Unknown Source)
    at org.apache.xerces.parsers.SAXParser.<init>(Unknown Source)
    at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.<init>(Unknown Source)
    at org.apache.xerces.jaxp.SAXParserImpl.<init>(Unknown Source)
    at org.apache.xerces.jaxp.SAXParserFactoryImpl.newSAXParser(Unknown Source)
    at org.jetbrains.idea.svn.commandLine.SvnCommandLineStatusClient.parseResult(SvnCommandLineStatusClient.java:138)
    at org.jetbrains.idea.svn.commandLine.SvnCommandLineStatusClient.doStatus(SvnCommandLineStatusClient.java:118)
    at org.jetbrains.idea.svn.SvnRecursiveStatusWalker.go(SvnRecursiveStatusWalker.java:79)
    at org.jetbrains.idea.svn.SvnChangeProvider.getChanges(SvnChangeProvider.java:89)
    at com.intellij.openapi.vcs.changes.ChangeListManagerImpl.a(ChangeListManagerImpl.java:686)
    at com.intellij.openapi.vcs.changes.ChangeListManagerImpl.a(ChangeListManagerImpl.java:596)
    at com.intellij.openapi.vcs.changes.ChangeListManagerImpl.d(ChangeListManagerImpl.java:480)
    at com.intellij.openapi.vcs.changes.ChangeListManagerImpl.access$1100(ChangeListManagerImpl.java:71)
    at com.intellij.openapi.vcs.changes.ChangeListManagerImpl$ActualUpdater.run(ChangeListManagerImpl.java:387)
    at com.intellij.openapi.vcs.changes.UpdateRequestsQueue$MyRunnable.run(UpdateRequestsQueue.java:260)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
    at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
    at java.util.concurrent.FutureTask.run(FutureTask.java:138)
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
    at java.lang.Thread.run(Thread.java:695)

Migliore esperienza con le seguenti opzioni (idea64.exe.vmoptions):

    -server
    -Xms1g
    -Xmx3g
    -Xss16m
    -XX: NewRatio = 3

    -XX: ReservedCodeCacheSize = 240m
    -XX: + UseCompressedOops
    -XX: SoftRefLRUPolicyMSPerMB = 50

    -XX: ParallelGCThreads = 4
    -XX: + UseConcMarkSweepGC
    XX: ConcGCThreads = 4

    -XX: + CMSClassUnloadingEnabled
    -XX: + CMSParallelRemarkEnabled
    -XX: CMSInitiatingOccupancyFraction = 65
    -XX: + CMSScavengeBeforeRemark
    -XX: + UseCMSInitiatingOccupancyOnly

    -XX: MaxTenuringThreshold = 1
    -XX: SurvivorRatio = 8
    -XX: + UseCodeCacheFlushing
    -XX: + AggressiveOpts
    -XX: -TraceClassUnloading
    -XX: + AlwaysPreTouch
    -XX: + TieredCompilation

    -Djava.net.preferIPv4Stack = true
    -Dsun.io.useCanonCaches = false
    -Djsse.enableSNIExtension = true
    -ea

Avvio intellij 75s -> 10s. Tutto quello che ho fatto è stato passare dall'uso dell'exe predefinito a 32 bit all'utilizzo dell'exe a 64 bit.

Per me il problema era una cartella nodes_modules con più di mille file. Ho dovuto contrassegnare la directory come esclusa.

Vedi anche questo elenco di possibili problemi.

Sono su 13.1 e ho scoperto che la seguente impostazione fa miracoli per me: Impostazioni IDE -> Editor -> Ritardo autoreparse (ms), che ho impostato su 1500 (il valore predefinito è 300).

Su un grande progetto, il compilatore e le ispezioni inizierebbero costantemente tra le interazioni. Il ritardo forse aiuta a ridurre la pressione dell'heap e generalmente rende l'intera esperienza molto più veloce. Anche la mia CPU è molto più interessante, il che probabilmente aiuta.

Ho risolto i miei problemi di prestazioni passando alla modalità a 32 bit. Sembra essere in relazione con JRE con cui funziona IntelliJ. Viene fornito con un JRE 1.7 a 32 bit che viene utilizzato all'avvio di idea.exe. Se avvii idea64.exe, utilizza un JRE a 64 bit installato sul sistema. Nel mio caso questo era un 1.6 JDK (quello che uso per lo sviluppo). Ciò ha reso IntelliJ quasi inutilizzabile.

Dopo aver installato un corretto JDK a 64 bit 1.7, tutto andava bene anche con la modalità a 64 bit.

Vedere la risposta sul sito Web dell'assistenza IntelliJ .

Nel mio caso sto sviluppando all'interno di Moodle che crea enormi file minimizzati JS e CSS. Una volta che ho excludedtesi i file minimizzati "memorizzati nella cache" dal progetto, InitelliJ ha funzionato di nuovo normalmente.

Ho avuto problemi simili con un avvio molto lento e problemi di heap, l'aumento della VM non ha fatto una grande differenza, ho solo ritardato l'inevitabile, la soluzione per me era invalidare la cache tramite File> InvalidateCaches / Restart.

https://www.jetbrains.com/help/idea/2016.1/cleaning-system-cache.html

Sto usando 13 dalla prima beta e non ho alcun problema. Forse sono le tue impostazioni specifiche. Forse il tuo progetto è cresciuto nel tempo e la memoria che hai dato a Idea inizialmente non è sufficiente per questo adesso? Prova a dare a Idea più memoria per lavorare con: http://www.jetbrains.com/idea/webhelp/increasing-memory-heap.html (istruzioni su come farlo).

La mia versione 13 di IntelliJ è notevolmente più lenta della versione 12 della mia esperienza. Esistono alcuni modi per accelerarlo, come aumentare le opzioni della macchina virtuale per intelliJ. Per es. Sto usando un progetto maven e per questo ho aumentato le opzioni di corridore e importatore a 4 GB. Ha reso le cose molto più veloci di prima.

Il mio caso particolare (Mac) è che ho modificato il file info.plist in modo da utilizzare java 1.7 * (per qualsiasi motivo) e funzionava come un cane assoluto.

Modificato di nuovo a 1.6 * e installato java 1.6, ed è stato veloce.

Stavo affrontando prestazioni lente con Intellij 2016.1 (64 bit) e JDK 1.8 (64 bit). Sono passato a

• 64 bit intellij
• 64 bit Java 8 come percorso JAVA_HOME (necessario per eseguire Intellij a 64 bit)
• Java 8 a 32 bit come JDK da utilizzare per i progetti Intellij (File -> Struttura del progetto | Impostazioni progetto -> Progetto | SDK progetto).

Con questa combinazione, ora le prestazioni di Intellij sono abbastanza buone.

La modifica del file idea.vmoptions è solo una soluzione temporanea fino al prossimo aggiornamento del prodotto. Consulta le pagine della guida di JetBrains per una soluzione più permanente all'impostazione di questi valori tramite le impostazioni vm - https://www.jetbrains.com/help/idea/tuning-the-ide.html

Aumenta le dimensioni dell'heap per il compilatore. Per impostazione predefinita, il valore è 700 m, che è troppo piccolo con un numero crescente di plugin.

Alla v2019.1 si trova qui:

Impostazioni -> Build, Execution, Deployment -> Compiler -> Build heap process process (Mbytes)

Dopo averne messo 4000 ho risolto gran parte dei miei problemi di prestazioni.

Il mio caso particolare: ho avuto un certo numero di method breakpointstempo mentre stavo eseguendo il mio codice in modalità debug, che ha rallentato il mio intelliJ.