Warum ist IntelliJ 13 IDEA nach dem Upgrade von Version 12 so langsam?

Während Sie IntelliJ 13 Ultimate Edition eine Woche lang verwenden, scheint es nur sehr langsam zu sein.

Zunächst stoppt die gesamte IDE von Zeit zu Zeit für etwa eine Sekunde. Die automatische Vervollständigung des Java-Editors ist im Vergleich zur Version 12 sehr langsam.

Ich habe nichts an den Standardeinstellungen geändert, außer ein Dracula-Thema zu verwenden.

Es scheint, dass dies kein eigenes Problem ist. Viele Leute schlugen vor, die Heap-Größe höher als die Standardgröße festzulegen oder den Cache zu leeren, aber ich habe diesen Vorschlag nicht überprüft oder getestet. Muss ich einige Einstellungen ändern, um die Leistung der neuen Version zu verbessern?

Ich hatte das gleiche Problem mit der Langsamkeit in IntelliJ 13 nach dem Upgrade von 12. Was für mich funktioniert hat, war, die idea64.vmoptions im bin-Ordner zu bearbeiten und den maximalen Heap auf 8 GB (512 MB) und den maximalen PermGen auf mindestens 1 GB festzulegen (war 300 MB). Beispiel unten:

-Xms128m
-Xmx8192m
-XX:MaxPermSize=1024m

Beim Neustart war es viel schneller.

Für IntelliJ 2020 bis 2017 auf dem Mac /Applications/IntelliJ IDEA.app/Contents/bin/idea.vmoptions

Auf einem Mac befindet sich diese Datei in folgendem Pfad:

Für IntelliJ 14 oder 15 auf Mac /Applications/IntelliJ IDEA 14.app/Contents/bin/idea.vmoptions

Für IntelliJ 13 auf Mac /Users/yourusername/Library/Preferences/IntelliJIdea13/idea.vmoptions

Der Updater von IntelliJ (seit 2017) scheint diese Änderung rückgängig zu machen, sodass Sie sie möglicherweise nach dem Update erneut anwenden müssen.

Unter Ubuntu Linux befindet sich diese Datei in diesem Pfad relativ zum Installationsverzeichnis:

idea-IU-135.475/bin/idea64.vmoptions

und für 2016.2:

 ~/.IdeaIC2016.2/idea64.vmoptions

Unter Windows 10 (hier gezeigte Community Edition) befinden sich diese Dateien in:

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

Mir ist aufgefallen, dass das Deaktivieren vieler Plug-Ins IntelliJ wirklich beschleunigt. Zum Beispiel entwickle ich keine Android-Anwendungen. Durch Deaktivieren der Plugins für die Android-Entwicklung wird die Ladezeit beschleunigt und das Programm läuft auf meinem Computer viel reibungsloser.

In meinem Fall scheint die GIT-Integration dazu zu führen, dass der Editor mit 13 frustrierend langsam ist.

Während der Eingabe und sogar der Kommentare bei aktivierter GIT-Integration friert die Benutzeroberfläche nach etwa 30 Zeichen etwa eine Sekunde lang ein. Es ist normalerweise nicht lang, aber sehr nervig.

Ich benutze GIT 1.7.8.0. Läuft unter Windows 7 64 mit einem Solid-State-Laufwerk und 12 GB RAM und einem Intel I7 mit 8 CPUs. Ich habe verschiedene Dinge ausprobiert, z. B. das Aktualisieren der option64.exe.vmoptions, um mehr Speicher zu verwenden, wie -Xmx2400m und -XX: MaxPermSize = 2400m, -XX: ParallelGCThreads = 6, aber das Problem wurde dadurch nicht behoben.

Das Git-Repository umfasst 1,3 Gigs mit 65.000 Dateien.

Ich habe ein neues "Grails" -Projekt in einem neuen Git-Repository erstellt, und es gibt kein Problem. Ich habe ein neues Grails-Projekt im vorhandenen großen Git-Repository erstellt, und Intellij ist langsam. Ich habe die Git-Integration deaktiviert, indem ich den Projekteinstellungsdialog geöffnet und den Git-Stamm gelöscht habe, und das Problem ist behoben.

Ich habe versucht, alle GIT-Hintergrundvorgänge über die 13-Benutzeroberfläche zu deaktivieren, aber es machte keinen Unterschied. Ich habe auch sowohl den integrierten als auch den nativen GIT-Modus ausprobiert, und es machte keinen Unterschied.

In meinem Fall scheint die Problemumgehung darin zu bestehen, die GIT-Integration zu deaktivieren, bis ich sie benötige, und dann einfach die Git-Wurzel erneut hinzuzufügen. Wenn jemand anderes das gleiche Problem überprüfen kann, melden wir es möglicherweise als Problem.

In meinem Fall wurde ein massiver Leistungsabfall durch IntelliJ verursacht, das unbeabsichtigt JDK / JRE 1.8 verwendet. Dies scheint die Renderleistung ziemlich stark zu beeinträchtigen und führt auch zu unerwarteten Abstürzen und Deadlocks.

Dies würde die IDE selbst für ein kleines ~ 3KLOC-Projekt unbrauchbar machen (Latenz von 1-2 Sekunden bei Operationen).

Stellen Sie einfach sicher, dass Sie JDK / JRE 1.7 verwenden, wenn Sie Intellij ausführen:

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

(oder was auch immer das Äquivalent für Ihr Betriebssystem ist)

Sie können die JRE, mit der Intellij ausgeführt wird, unter Hilfe -> Info -> JRE überprüfen.

Nun, ich kann nicht auf den obigen Beitrag von Engineer Dollery antworten, weil ich noch keine 50 Wiederholungen habe ... aber ich habe das Gleiche bemerkt. Ein Problem wurde bereits in Bezug auf hg4idea gemeldet: http://youtrack.jetbrains.com/issue/IDEA-118529 .

Es gibt noch keine Lösung, außer das hg4idea-Plugin zu deaktivieren. Aber wenn sich herausstellt, dass dies Ihr Problem ist, stimmen Sie für den Fehler!

Bearbeiten: JetBrains hat den Fehler in Build IU-138-815 behoben!

Ich hatte ein ähnliches Problem. In diesem Fall war es das Subversion-Plug-In. (Mac Mavericks, SVN Version 1.7.10) Nachdem ich diesen IntelliJ deaktiviert hatte, wurde er wieder verwendbar.

Habe das von jstack bekommen:

"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)

anderer Lauf:

"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)

Beste Erfahrung mit folgenden Optionen (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

75s -> 10s Intellij-Start. Ich habe nur von der Standard-32-Bit-Exe zur 64-Bit-Exe gewechselt.

Für mich war das Problem ein Ordner "node_modules" mit mehr als tausend Dateien. Ich musste das Verzeichnis als ausgeschlossen markieren.

Siehe auch diese Liste möglicher Probleme.

Ich bin auf 13.1 und habe festgestellt, dass die folgende Einstellung Wunder für mich bewirkt: IDE-Einstellungen -> Editor -> Autoreparse-Verzögerung (ms), die ich auf 1500 eingestellt habe (Standard ist 300).

Bei einem großen Projekt würden der Compiler und die Inspektionen zwischen den Interaktionen ständig beginnen. Die Verzögerung hilft vielleicht dabei, den Druck auf den Haufen zu reduzieren und die gesamte Erfahrung im Allgemeinen viel schneller zu machen. Meine CPU ist auch viel cooler, was wahrscheinlich hilft.

Ich habe meine Leistungsprobleme gelöst, indem ich in den 32-Bit-Modus gewechselt habe. Es scheint mit der JRE zu tun zu haben, mit der IntelliJ läuft. Es wird mit einer 32-Bit-JRE von 1,7 geliefert, die beim Starten von idea.exe verwendet wird. Wenn Sie idea64.exe starten, wird eine auf dem System installierte 64-Bit-JRE verwendet. In meinem Fall war dies ein 1.6 JDK (das ich für die Entwicklung verwende). Dies führte dazu, dass IntelliJ nahezu unbrauchbar wurde.

Nach der Installation eines richtigen 64-Bit-1.7-JDK war auch im 64-Bit-Modus alles in Ordnung.

Die Antwort finden Sie auf der IntelliJ Support -Website.

In meinem Fall entwickle ich in Moodle, das riesige JS- und CSS-minimierte Dateien erstellt. Nachdem ich diese excludedminimierten Dateien aus dem Projekt "zwischengespeichert" hatte, lief InitelliJ wieder normal.

Ich hatte ähnliche Probleme mit einem sehr langsamen Start und Heap-Problemen. Das Erhöhen der VM machte keinen großen Unterschied, verzögerte nur das Unvermeidliche. Die Lösung für mich bestand darin, den Cache über Datei> InvalidateCaches / Restart ungültig zu machen.

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

Ich benutze 13 seit der frühen Beta und habe überhaupt keine Probleme. Vielleicht sind es Ihre spezifischen Einstellungen. Vielleicht ist Ihr Projekt im Laufe der Zeit gewachsen und die Erinnerung, die Sie Idea ursprünglich gegeben haben, reicht jetzt nicht aus? Versuchen Sie, Idea mehr Speicherplatz für die Arbeit zu geben: http://www.jetbrains.com/idea/webhelp/increasing-memory-heap.html (Anweisungen dazu).

IntelliJ Version 13 ist meiner Erfahrung nach deutlich langsamer als die Version 12. Es gibt einige Möglichkeiten, dies zu beschleunigen, z. B. das Erhöhen der VM-Optionen für IntelliJ. Zum Beispiel. Ich verwende ein Maven-Projekt und habe dafür die Runner- und Importer-Optionen auf 4 GB erhöht. Es machte die Dinge viel schneller als zuvor.

Mein besonderer Fall (Mac) war, dass ich die info.plist so bearbeitet habe, dass sie Java 1.7 * verwendet (aus welchem ​​Grund auch immer), und sie lief wie ein absoluter Hund.

Zurück zu 1.6 * geändert und Java 1.6 installiert, und es war schnell.

Mit Intellij 2016.1 (64-Bit) und JDK 1.8 (64-Bit) war ich mit einer schleppenden Leistung konfrontiert. Ich wechselte zu

• 64 Bit Intellij
• 64-Bit-Java 8 als JAVA_HOME-Pfad (Dies ist erforderlich, um 64-Bit-Intellij auszuführen)
• 32-Bit-Java 8 als JDK zur Verwendung für Intellij-Projekte (Datei -> Projektstruktur | Projekteinstellungen -> Projekt | Projekt-SDK).

Durch diese Kombination ist die Intellij-Leistung jetzt ganz in Ordnung.

Das Bearbeiten der Datei idea.vmoptions ist nur eine vorübergehende Lösung bis zum nächsten Produktupdate. Auf den Hilfeseiten von JetBrains finden Sie eine dauerhaftere Lösung zum Festlegen dieser Werte über die VM-Einstellungen - https://www.jetbrains.com/help/idea/tuning-the-ide.html

Erhöhen Sie die Heap-Größe für den Compiler. Standardmäßig ist der Wert 700 m, was mit zunehmender Anzahl von Plugins viel zu klein ist.

Bei v2019.1 befindet es sich hier:

Einstellungen -> Erstellen, Ausführen, Bereitstellen -> Compiler -> Größe des Build-Prozessheaps (MB)

Nachdem ich 4000 dort platziert hatte, löste es die meisten meiner Leistungsprobleme.

Mein besonderer Fall: Ich hatte einige Zeit, method breakpointswährend ich meinen Code im Debug-Modus ausführte, was meine Intelligenz langsam machte.