Si vous utilisez IntelliJ 13 Ultimate Edition pendant une semaine, cela semble vraiment très lent.
Tout d’abord, l’ensemble IDE s’arrête une seconde environ de temps en temps. La complétion automatique de l'éditeur Java est vraiment lente comparée à la version 12.
Je n'ai rien changé aux paramètres par défaut autre que d'utiliser un thème Dracula.
Il semble que ce ne soit pas un problème de ma part. De nombreuses personnes ont suggéré de définir une taille de segment supérieure à celle par défaut ou d'effacer le cache, mais je n'ai ni vérifié ni testé ces suggestions. Dois-je modifier certains paramètres pour améliorer les performances de la nouvelle version?
J'ai remarqué que la désactivation de nombreux plug-ins contribue réellement à 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 causer la lenteur frustrante de l’éditeur avec 13.
Lors de la frappe, même des commentaires, avec l'intégration de GIT activée, l'interface utilisateur se bloque après environ 30 caractères, environ une seconde. Ce n'est généralement pas long, mais très énervant.
J'utilise GIT 1.7.8.0. Fonctionnant sous Windows 7 64 avec un lecteur à semi-conducteurs et 12 Go de RAM et un processeur Intel I7 avec 8 processeurs. J'ai essayé diverses choses, telles que la mise à jour de idea64.exe.vmoptions pour utiliser davantage de mémoire, comme -Xmx2400m et -XX: MaxPermSize = 2400m, -XX: ParallelGCThreads = 6, mais le problème n'a pas été résolu.
Le référentiel git contient 1,3 Go et 65 000 fichiers.
J'ai créé un nouveau projet "grails" dans un nouveau référentiel git, et il n'y a pas de 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 de git. Le problème a disparu.
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 changé. J'ai également essayé les modes natif et intégré de GIT, et cela n'a fait aucune différence.
Dans mon cas, la solution semble être de désactiver l'intégration de GIT jusqu'à ce que j'en ai besoin, puis de simplement rajouter la racine git. Si quelqu'un d'autre peut vérifier le même problème, nous pourrions le signaler comme un problème.
Dans mon cas dégradation massive des performances a été causée par IntelliJ sans le vouloir en utilisant JDK/JRE 1.8. Cela semble affecter considérablement les performances de rendu et conduit également à des crashs et des blocages inattendus.
Cela rendrait le IDE inutilisable (latence de 1-2 sur les opérations) même pour un petit projet ~ 3KLOC.
Assurez-vous simplement que vous utilisez JDK/JRE 1.7 lorsque vous utilisez 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 dans Aide -> À propos de -> JRE.
Eh bien, je ne peux pas répondre au message de Engineer 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 vous pose problème, votez pour le bogue!
Edit: JetBrains a corrigé le bogue dans la construction 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) Après avoir désactivé cette interface, IntelliJ est à nouveau utilisé.
J'ai eu ça 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)
Pour moi, le problème était un dossier node_modules avec plus de mille fichiers. Je devais marquer le répertoire comme exclu.
Voir aussi this liste des problèmes possibles.
Meilleure expérience des options suivantes (idea64.exe.vmoptions):
-serveur -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: + ToujoursPreTouch -XX: + TieredCompilation -Djava.net.preferIPv4Stack = true -Dsun.io.useCanonCaches = false -Djsse.enableSNIExtension = true -ea
Démarrage de l'intellij de 75 à 10 ans. Tout ce que je fis, c’est de passer de l’exécutable 32 bits par défaut à l’exécutable 64 bits.
Je suis sur 13.1 et j'ai trouvé le réglage suivant qui fonctionnait à merveille pour moi: IDE Paramètres -> Editeur -> Délai de création automatique (ms), que j'ai défini sur 1500 (la valeur par défaut est 300).
Sur un grand projet, le compilateur et les inspections déclencheraient en permanence les interactions. Ce délai peut aider à réduire la pression du tas et à rendre l’ensemble de l’expérience beaucoup plus rapide. Mon unité centrale est beaucoup plus froide aussi, ce qui aide probablement.
J'ai résolu mes problèmes de performances en passant au mode 32 bits. Cela 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 du programme idea.exe. Si vous démarrez idea64.exe, il utilise un JRE 64 bits installé sur le système. Dans mon cas, il s’agissait d’un JDK 1.6 (celui que j’utilise pour le développement). Cela a rendu IntelliJ presque inutilisable.
Après l’installation d’un JDK 1.7 64 bits approprié, tout se passait bien avec le mode 64 bits.
Voir la réponse sur le site Web - IntelliJ Support .
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 excluded
ces 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 VM ne faisant pas une énorme différence, j'ai simplement 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
Augmentez la taille du tas pour le compilateur. Par défaut, la valeur est 700m, ce qui est beaucoup trop petit avec le nombre croissant de plugins.
À v2019.1, il se trouve ici:
Paramètres -> construction, exécution, déploiement -> compilateur -> taille de segment de mémoire du processus de génération (en Mo)
Après avoir mis 4000 là-bas, cela a résolu la plupart de mes problèmes de performances.
Je faisais face à des performances médiocres avec Intellij 2016.1 (64 bits) et JDK 1.8 (64 bits). Je suis passé à
Grâce à cette combinaison, les performances d’Intellij sont tout à fait acceptables.
La version 13 d’IntelliJ est nettement plus lente que la version 12 de mon expérience. Il y a plusieurs façons de l'accélérer, comme augmenter les options VM pour intelliJ. Pour par exemple. J'utilise un projet Maven, et pour cela, j'ai augmenté les options de coureur et d'importateur à 4 Go. Cela a rendu les choses beaucoup plus rapides qu'avant.
Mon cas particulier (Mac) est celui où j’ai édité le fichier info.plist pour utiliser Java 1.7 * (quelle que soit la raison), et il fonctionnait comme un chien absolu.
Ramené à 1.6 * et installé Java 1.6, et c'était rapide.
J'utilise 13 depuis le début de la version 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 avec le temps et que la mémoire que vous avez donnée à l'origine, Idea, ne lui suffit pas maintenant? Essayez de donner à Idea plus de mémoire avec laquelle travailler: http://www.jetbrains.com/idea/webhelp/increasing-memory-heap.html (instructions sur la procédure à suivre).
La modification du fichier idea.vmoptions n’est qu’une solution temporaire jusqu’à la prochaine mise à jour du produit. Voir les pages d’aide de JetBrains pour une solution plus permanente permettant de définir ces valeurs via les paramètres vm - https://www.jetbrains.com/help/idea/tuning-the-ide.html