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

En utilisant IntelliJ 13 ultimate edition pendant une semaine, cela semble vraiment lent.

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

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

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

197
demandé sur Brian 2013-12-12 17:54:51

17 réponses

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 était d'éditer l'idea64.vmoptions dans le dossier bin et définir le tas max à 8 Go (était de 512 Mo) et le PermGen Max à au moins 1 Go (était de 300 Mo).Exemple ci-dessous:

-Xms128m
-Xmx8192m
-XX:MaxPermSize=1024m

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

Sur un Mac, ce fichier se trouve dans ce chemin: /Users/yourusername/Library/Preferences/IntelliJIdea13/idea.vmoptions

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

Pour IntelliJ 2016, 2017 ou supérieur sur Mac /Applications/IntelliJ IDEA.app/Contents/bin/idea.vmoptions

La mise à jour 2017 D'IntelliJ semble annuler cette modification, vous devrez peut-être la réappliquer après la mise à jour.

Sous 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

Sous Windows 10 (Community edition montré ici) ces fichiers sont situés dans:

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

237
répondu Jason D 2017-07-24 01:01:52

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.

41
répondu Nathan 2013-12-12 14:48:35

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.

25
répondu mark 2014-03-12 01:15:54

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.

14
répondu paul-g 2014-10-13 10:30:27

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!

13
répondu tmeans 2014-05-21 02:43:04

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)
8
répondu Jochen Bedersdorfer 2014-12-31 09:12:13

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.

5
répondu Dennis 2014-05-17 19:26:45

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.

5
répondu DanT 2014-07-21 21:38:04

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
5
répondu Dogan Eren 2016-05-09 05:16:26

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.

4
répondu jonathanChap 2014-10-09 13:59:31

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 .

3
répondu sorencito 2014-04-04 06:37:59

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.

2
répondu ktamlyn 2014-11-06 11:56:37

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

2
répondu user3524762 2016-07-13 05:24:46

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

0
répondu Engineer Dollery 2013-12-13 00:26:40

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.

0
répondu Aditya Satyavada 2014-10-06 17:40:45

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.

0
répondu user3769865 2014-10-13 01:42:01

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.

0
répondu WingsOfFire 2016-05-09 07:02:41