Pourquoi IntelliJ 13 IDEA est-il si lent après la mise à niveau de la version 12?

J'ai remarqué que la désactivation de nombreux plug-ins aide vraiment à accélérer IntelliJ. Par exemple, Je ne développe pas D'Applications Android. Désactiver les plugins liés au développement Android accélère le temps de chargement et rend le programme beaucoup plus fluide sur ma machine.

Dans mon cas, l'intégration de GIT semble entraîner une lenteur frustrante de l'éditeur avec 13.

Lors de la saisie, même des commentaires, avec l'intégration GIT activée, après environ 30 caractères, l'interface utilisateur se fige pendant une seconde environ. Ce n'est généralement pas long, mais très ennuyeux.

J'utilise GIT 1.7.8.0. Fonctionnant sous Windows 7 64 avec un lecteur à état solide et 12 Go de ram et un intel I7 avec 8 processeurs. J'ai essayé diverses choses, comme mettre à jour l'idea64.EXE.vmoptions pour utiliser plus de mémoire, comme -Xmx2400m et-XX: MaxPermSize = 2400m, - XX: ParallelGCThreads=6, mais cela n'a pas résolu le problème.

Le dépôt git est de 1,3 concert avec 65 000 fichiers.

J'ai créé un nouveau projet "grails" dans un nouveau dépôt git, et il n'y a pas de problème. J'ai créé un nouveau projet grails dans le grand dépôt git existant, et intellij est lent. J'ai désactivé l'intégration git en ouvrant la boîte de dialogue Paramètres du projet et en supprimant la racine git, et le problème disparaît.

J'ai essayé de désactiver tout les opérations D'arrière-plan GIT via l'interface utilisateur 13, mais cela n'a pas fait de différence. J'ai également essayé les modes git intégré et natif, et cela n'a fait aucune différence.

Dans mon cas, la solution de contournement semble être de désactiver L'intégration GIT jusqu'à ce que j'en ai besoin, et de simplement ré-ajouter la racine git. Si quelqu'un d'autre peut vérifier le même problème, on peut signaler un problème.

Dans mon cas la dégradation massive des performances a été causée par IntelliJ en utilisant involontairement JDK / JRE 1.8. Cela semble affecter les performances de rendu assez mal et conduit également à des plantages et des blocages inattendus.

Cela rendrait l'IDE inutilisable (latence de 1-2s sur les opérations) même pour un petit projet ~3KLOC.

Assurez-vous simplement d'utiliser JDK / JRE 1.7 lors de l'exécution d'intellij:

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

(ou quel que soit l'équivalent de votre système d'exploitation)

Vous pouvez vérifiez le JRE utilisé pour exécuter intellij sous Help - > About - > JRE.

Eh bien, je ne peux pas répondre au post de L'ingénieur Dollery ci-dessus parce que je n'ai pas encore 50 représentants... mais j'ai remarqué la même chose. Un problème a déjà été signalé concernant hg4idea: http://youtrack.jetbrains.com/issue/IDEA-118529 .

Il n'y a pas encore de solution sauf pour désactiver le plugin hg4idea. Mais si cela s'avère être votre problème, voter pour le bug!

Edit: JetBrains a corrigé le bug dans build IU-138-815!

J'ai eu un problème similaire. Dans ce cas, c'était le plug-in Subversion. (Mac Mavericks, SVN version 1.7.10) Une fois que j'ai désactivé cet IntelliJ est devenu Utilisable à nouveau.

Obtenu ceci de 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)

Autre exécution:

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

75s - > 10S démarrage intellij. Tout ce que j'ai fait était de passer de l'utilisation de l'exe 32 bits par défaut à l'utilisation de l'exe 64 bits.

Pour moi, le problème était un dossier nodes_modules avec plus de mille fichiers. J'ai dû marquer le répertoire comme exclus.

Voir aussi Cette Liste des problèmes possibles.

Meilleure expérience avec les options suivantes (idea64.EXE.vmoptions):

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

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

    -XX:+UseParNewGC
    -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

Je suis sur 13.1, et j'ai trouvé le paramètre suivant fonctionne à merveille pour moi: IDE Settings - > Editor -> Autoreparse delay (ms), que j'ai mis à 1500 (par défaut est 300).

Sur un grand projet, le compilateur et les inspections démarreraient constamment entre les interactions. Le retard peut-être aider à réduire la pression de tas et généralement rendre l'expérience entière beaucoup plus rapide. Mon cpu est beaucoup plus cool aussi, ce qui aide probablement.

J'ai résolu mes problèmes de performance en passant au mode 32 bits. Il semble être lié au JRE avec lequel IntelliJ fonctionne. Il est livré avec un 32 bit 1.7 JRE qui est utilisé lors du démarrage idea.EXE. Si vous démarrez idea64.exe, il utilise un JRE 64 bits installé sur le système. Dans mon cas, c'était un 1.6 JDK (celui que j'utilise pour le développement). Cela a causé IntelliJ à être presque inutilisable.

Après avoir installé un bon JDK 64 bits 1.7, tout allait bien avec le mode 64 bits.

Voir la réponse sur le site web IntelliJ Support .

Dans mon cas, je développe dans Moodle qui crée d'énormes fichiers minifiés JS et CSS. Une fois que j'ai excluded ces fichiers" mis en cache " minifiés du projet, InitelliJ a fonctionné normalement à nouveau.

J'ai eu des problèmes similaires avec un démarrage très lent et des problèmes de tas, l'augmentation de la VM n'a pas fait une énorme différence, juste retardé l'inévitable, le correctif pour moi était d'invalider le cache via File > InvalidateCaches / Restart.

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

J'utilise 13 depuis le début de la bêta et je n'ai aucun problème. Peut-être que ce sont vos paramètres spécifiques. Peut-être que votre projet a grandi au fil du temps et que la mémoire que vous avez donnée à L'origine N'est pas suffisante pour cela maintenant? Essayez de donner à Idea plus de mémoire pour travailler avec: http://www.jetbrains.com/idea/webhelp/increasing-memory-heap.html (instructions sur la façon de le faire).

IntelliJ version 13 est nettement plus lent que la version 12 de mon expérience. Il existe plusieurs façons de l'accélérer, Comme augmenter les options de VM pour intelliJ. Pour eg. J'utilise un projet maven, et pour cela j'ai augmenté les options runner et importer à 4GB . Cela a rendu les choses beaucoup plus rapides qu'avant.

Mon cas particulier (Mac) a été j'ai édité l'info.plist pour utiliser java 1.7* (Pour une raison quelconque), et il a couru comme un chien absolu.

Est revenu à 1.6* et a installé java 1.6, et c'était rapide.

Je faisais face à des performances lentes avec Intellij 2016.1 (64 bits) et JDK 1.8 (64 bits). Je suis passé à

• 64 bits intellij
• Java 8 64 bits comme chemin JAVA_HOME (ceci est nécessaire pour exécuter Intellij 64 bits)
• Java 8 32 bits comme JDK à utiliser pour les projets Intellij (fichier - > Structure du projet / Paramètres du projet - > Projet / SDK du projet).

Par cette combinaison, maintenant la performance Intellij est tout à fait OK.