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

Tout en utilisant IntelliJ 13 Ultimate Edition pendant une semaine, cela semble vraiment très lent.

Tout d'abord, l'EDI entier s'arrête pendant une seconde environ de temps en temps. La saisie automatique de l'éditeur Java est vraiment lente par rapport à la version 12.

Je n'ai rien changé par rapport aux paramètres par défaut autre que l'utilisation d'un thème Dracula.

Il semble que ce ne soit pas mon problème. Beaucoup de gens ont suggéré de définir une taille de tas supérieure à celle par défaut ou de vider le cache, mais je n'ai pas vérifié ou testé ces suggestions. Dois-je modifier certains paramètres pour améliorer les performances de la nouvelle version?

J'ai eu le même problème avec la lenteur dans IntelliJ 13 après la mise à niveau de 12. Ce qui a fonctionné pour moi a été d'éditer les idées64.vmoptions dans le dossier bin et de définir le tas max à 8 Go (au lieu de 512 Mo) et le Max PermGen à au moins 1 Go (était de 300 Mo) .Exemple ci-dessous:

-Xms128m
-Xmx8192m
-XX:MaxPermSize=1024m

Au redémarrage, c'était beaucoup plus rapide.

Pour IntelliJ 2020 remontant à 2017 sur Mac /Applications/IntelliJ IDEA.app/Contents/bin/idea.vmoptions

Sur un Mac, ce fichier se trouve dans ce chemin:

Pour IntelliJ 14 ou 15 sur Mac /Applications/IntelliJ IDEA 14.app/Contents/bin/idea.vmoptions

Pour IntelliJ 13 sur Mac /Users/yourusername/Library/Preferences/IntelliJIdea13/idea.vmoptions

Le programme de mise à jour d'IntelliJ (depuis 2017) semble annuler cette modification, vous devrez donc peut-être la réappliquer après la mise à jour.

Sur Ubuntu Linux, ce fichier se trouve dans ce chemin par rapport au répertoire d'installation:

idea-IU-135.475/bin/idea64.vmoptions

et pour 2016.2:

 ~/.IdeaIC2016.2/idea64.vmoptions

Sur Windows 10 (édition communautaire illustrée ici), ces fichiers se trouvent dans:

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

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 ralentir énormément l'éditeur avec 13.

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

J'utilise GIT 1.7.8.0. Fonctionnant sur Windows 7 64 avec un disque SSD et 12 Go de RAM et un Intel I7 avec 8 CPU. J'ai essayé différentes choses, comme la mise à jour des options idea64.exe.vm 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 référentiel git est de 1,3 concerts avec 65 000 fichiers.

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

J'ai essayé de désactiver toutes 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 intégrés et natifs de GIT, et cela n'a fait aucune différence.

Dans mon cas, la solution semble être de désactiver l'intégration GIT jusqu'à ce que j'en ai besoin, puis de simplement ajouter à nouveau la racine git. Si quelqu'un d'autre peut vérifier le même problème, nous pouvons le signaler comme un problème.

Dans mon cas, une dégradation massive des performances a été causée par IntelliJ utilisant involontairement JDK / JRE 1.8. Cela semble affecter très gravement les performances de rendu et entraîne également des plantages et des blocages inattendus.

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

Assurez-vous simplement que vous utilisez 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 pour votre système d'exploitation)

Vous pouvez vérifier le JRE utilisé pour exécuter intellij sous Aide -> À propos -> JRE.

Eh bien, je ne peux pas répondre au message d'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, votez pour le bug!

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

J'avais 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 redevenu utilisable.

J'ai 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 course:

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

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

    -serveur
    -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: + compilation à plusieurs niveaux

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

75s -> 10s démarrage intellij. Tout ce que j'ai fait, c'est passer de l'exe 32 bits par défaut à 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 exclu.

Consultez également cette liste de problèmes possibles.

Je suis sur 13.1, et j'ai trouvé que le paramètre suivant fonctionne à merveille pour moi: Paramètres IDE -> Editeur -> Délai d'autoréparation (ms), que j'ai défini à 1500 (la valeur par défaut est 300).

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

J'ai résolu mes problèmes de performances en passant au mode 32 bits. Il semble être lié au JRE avec lequel IntelliJ fonctionne. Il est livré avec un JRE 1.7 32 bits qui est utilisé lors du démarrage de 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 JDK 1.6 (celui que j'utilise pour le développement). Cela a rendu IntelliJ presque inutilisable.

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

Consultez la réponse sur le site Web du support IntelliJ .

Dans mon cas, je développe au sein de Moodle qui crée d'énormes fichiers minifiés JS et CSS. Une fois que j'ai excludedthèses les fichiers minifiés "mis en cache" du projet, InitelliJ s'est à nouveau exécuté normalement.

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, a juste retardé l'inévitable, le correctif pour moi était d'invalider le cache via Fichier> InvalidateCaches / Restart.

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

J'utilise 13 depuis la première version bêta et je n'ai aucun problème. C'est peut-être 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 à Idea à l'origine n'est plus suffisante pour lui 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 procéder).

La version 13 d'IntelliJ est nettement plus lente que la version 12 d'après mon expérience. Il existe plusieurs façons de l'accélérer, comme l'augmentation des options de VM pour intelliJ. Par exemple. J'utilise un projet maven, et pour cela j'ai augmenté les options de runner et d'importateur à 4 Go. Cela a rendu les choses beaucoup plus rapides qu'auparavant.

Mon cas particulier (Mac) était que j'avais édité l'info.plist pour utiliser java 1.7 * (pour une raison quelconque), et il fonctionnait comme un chien absolu.

Changé en 1.6 * et installé java 1.6, et c'était rapide.

J'étais confronté à des performances lentes avec Intellij 2016.1 (64 bits) et JDK 1.8 (64 bits). Je suis passé à

• Intellij 64 bits
• Java 8 64 bits comme chemin JAVA_HOME (requis pour exécuter Intellij 64 bits)
• Java 8 bits 32 comme JDK à utiliser pour les projets Intellij (Fichier -> Structure du projet | Paramètres du projet -> Projet | SDK du projet).

Grâce à cette combinaison, les performances d'Intellij sont maintenant tout à fait correctes.

La modification du fichier idea.vmoptions n'est qu'une solution temporaire jusqu'à la prochaine mise à jour du produit. Voir les pages d'aide JetBrains pour une solution plus permanente pour définir ces valeurs via les paramètres vm - https://www.jetbrains.com/help/idea/tuning-the-ide.html

Augmentez la taille du segment de mémoire pour le compilateur. Par défaut, la valeur est 700m, ce qui est beaucoup trop petit avec un nombre croissant de plugins.

À v2019.1, il se trouvait ici:

Paramètres -> Build, Execution, Deployment -> Compiler -> Build process heap size (Mbytes)

Après avoir mis 4000, il a résolu la plupart de mes problèmes de performances.

Mon cas particulier: j'en ai eu plusieurs method breakpointspendant que j'exécutais mon code en mode débogage, ce qui a ralenti mon intelligence.