¿Por qué IntelliJ 13 IDEA es tan lento después de actualizar desde la versión 12?

Mientras usa IntelliJ 13 ultimate edition durante una semana, parece muy lento.

En primer lugar, todo el IDE se detiene por un segundo más o menos de vez en cuando. El autocompletado del editor de Java es realmente lento en comparación con la versión 12.

No he cambiado nada de la configuración predeterminada que no sea el uso de un tema de Drácula.

Parece que esto no es un problema mío. Muchas personas sugirieron configurar el tamaño del montón más alto que el predeterminado, o borrar el caché, pero no he verificado ni probado estas sugerencias. ¿Necesito cambiar alguna configuración para mejorar el rendimiento de la nueva versión?

Tuve el mismo problema con la lentitud en IntelliJ 13 después de actualizar desde 12. Lo que funcionó para mí fue editar la idea64.vmoptions en la carpeta bin y configurar el almacenamiento dinámico máximo en 8 GB (512 MB) y Max PermGen en al menos 1 GB (antes 300 MB). Ejemplo a continuación:

-Xms128m
-Xmx8192m
-XX:MaxPermSize=1024m

Al reiniciar fue mucho más rápido.

Para IntelliJ 2020 volviendo a 2017 en Mac /Applications/IntelliJ IDEA.app/Contents/bin/idea.vmoptions

En una Mac, este archivo se encuentra en esta ruta:

Para IntelliJ 14 o 15 en Mac /Applications/IntelliJ IDEA 14.app/Contents/bin/idea.vmoptions

Para IntelliJ 13 en Mac /Users/yourusername/Library/Preferences/IntelliJIdea13/idea.vmoptions

El actualizador de IntelliJ (desde 2017) parece revertir este cambio, por lo que es posible que deba volver a aplicarlo después de la actualización.

En Ubuntu Linux, este archivo se encuentra en esta ruta relativa al directorio de instalación:

idea-IU-135.475/bin/idea64.vmoptions

y para 2016.2:

 ~/.IdeaIC2016.2/idea64.vmoptions

En Windows 10 (la edición comunitaria se muestra aquí) estos archivos se encuentran en:

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

Noté que deshabilitar muchos de los complementos realmente ayuda a acelerar IntelliJ. Por ejemplo, no estoy desarrollando aplicaciones de Android. Desactivar los complementos relacionados con el desarrollo de Android acelera el tiempo de carga y hace que el programa funcione mucho mejor en mi máquina.

En mi caso, la integración de GIT parece estar causando que el editor sea frustrantemente lento con 13.

Mientras escribe, incluso comentarios, con la integración GIT activada, después de unos 30 caracteres, la interfaz de usuario se congela por un segundo más o menos. Por lo general, no es largo, pero es muy molesto.

Estoy usando GIT 1.7.8.0. Se ejecuta en Windows 7 64 con una unidad de estado sólido y 12 gigas de RAM y un Intel I7 con 8 CPU. Intenté varias cosas, como actualizar la idea64.exe.vmoptions para usar más memoria, como -Xmx2400m y -XX: MaxPermSize = 2400m, -XX: ParallelGCThreads = 6, pero no solucionó el problema.

El repositorio de git es de 1.3 conciertos con 65,000 archivos.

Creé un nuevo proyecto "grails" en un nuevo repositorio git, y no hay problema. Creé un nuevo proyecto de Grails en el repositorio git grande existente, e intellij es lento. Desactivé la integración de git abriendo el cuadro de diálogo de configuración del proyecto y eliminando la raíz de git, y el problema desaparece.

Traté de deshabilitar todas las operaciones en segundo plano GIT a través de la interfaz de usuario 13, pero no hizo la diferencia. También probé los modos GIT incorporado y nativo, y no hizo ninguna diferencia.

En mi caso, la solución parece ser deshabilitar la integración de GIT hasta que la necesite, y luego simplemente volver a agregar la raíz de git. Si alguien más puede verificar el mismo problema, entonces podríamos informarlo como un problema.

En mi caso, la degradación masiva del rendimiento fue causada por IntelliJ sin querer usando JDK / JRE 1.8. Esto parece afectar el rendimiento de renderizado bastante mal y también conduce a algunos bloqueos inesperados y puntos muertos.

Esto dejaría el IDE inutilizable (latencia de 1-2s en las operaciones) incluso para un pequeño proyecto ~ 3KLOC.

Solo asegúrese de estar utilizando JDK / JRE 1.7 cuando ejecute intellij:

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

(o lo que sea equivalente para su sistema operativo)

Puede verificar el JRE que se está utilizando para ejecutar intellij en Ayuda -> Acerca de -> JRE.

Bueno, no puedo responder a la publicación del ingeniero Dollery anterior porque todavía no tengo 50 repeticiones ... pero he notado lo mismo. Ya se ha informado de un problema con respecto a hg4idea: http://youtrack.jetbrains.com/issue/IDEA-118529 .

Todavía no hay solución, excepto para deshabilitar el complemento hg4idea. Pero si ese es tu problema, ¡vota por el error!

Editar: ¡JetBrains ha corregido el error en la compilación IU-138-815!

Tuve un problema similar. En ese caso, fue el complemento Subversion. (Mac Mavericks, SVN versión 1.7.10) Una vez que desactivé este IntelliJ volvió a ser utilizable.

Tengo esto 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)

otra carrera:

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

La mejor experiencia con las siguientes opciones (idea64.exe.vmoptions):

    -servidor
    -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: + UseCMSInitiatingOccupancyOncupaly

    -XX: MaxTenuringThreshold = 1
    -XX: SurvivorRatio = 8
    -XX: + UseCodeCacheFlushing
    -XX: + Opciones agresivas
    -XX: -TraceClassUnloading
    -XX: + AlwaysPreTouch
    -XX: + Compilación escalonada

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

75s -> 10s intellij startup. Todo lo que hice fue cambiar de usar el exe predeterminado de 32 bits a usar el exe de 64 bits.

Para mí, el problema era una carpeta node_modules con más de mil archivos. Tuve que marcar el directorio como excluido.

Consulte también esta lista de posibles problemas.

Estoy en 13.1, y he encontrado que la siguiente configuración funciona de maravilla para mí: Configuración IDE -> Editor -> Autoreparse delay (ms), que he configurado en 1500 (el valor predeterminado es 300).

En un proyecto grande, el compilador y las inspecciones comenzarían constantemente entre interacciones. El retraso tal vez ayude a reducir la presión del montón y, en general, haga que toda la experiencia sea mucho más rápida. Mi CPU también es mucho más fría, lo que probablemente ayude.

He resuelto mis problemas de rendimiento al cambiar al modo de 32 bits. Parece estar relacionado con el JRE con el que se ejecuta IntelliJ. Se entrega con un JRE 1.7 de 32 bits que se utiliza al iniciar idea.exe. Si inicia idea64.exe, utiliza un JRE de 64 bits instalado en el sistema. En mi caso, este era un 1.6 JDK (el que uso para el desarrollo). Esto hizo que IntelliJ fuera casi inutilizable.

Después de instalar un JDK 1.7 de 64 bits adecuado, todo estaba bien con el modo de 64 bits también.

Vea la respuesta en el sitio web de IntelliJ Support .

En mi caso, estoy desarrollando dentro de Moodle que crea enormes archivos minificados JS y CSS. Una vez que excludedtesis "minifundé" los archivos minificados del proyecto, InitelliJ volvió a funcionar normalmente.

Tuve problemas similares con un inicio muy lento y problemas de almacenamiento dinámico, el aumento de VM no hizo una gran diferencia, solo retrasó lo inevitable, la solución para mí fue invalidar el caché a través de Archivo> InvalidateCaches / Restart.

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

He estado usando 13 desde la versión beta temprana y no tengo ningún problema. Quizás sea su configuración específica. ¿Tal vez su proyecto ha crecido con el tiempo y la memoria que le dio a Idea originalmente no es suficiente ahora? Intente darle a Idea más memoria para trabajar: http://www.jetbrains.com/idea/webhelp/increasing-memory-heap.html (instrucciones sobre cómo hacerlo).

La versión 13 de IntelliJ es notablemente más lenta que la versión 12 de mi experiencia. Hay algunas formas de acelerarlo, como aumentar las opciones de VM para intelliJ. Por ej. Estoy usando un proyecto maven, y para eso aumenté las opciones de corredor e importador a 4GB. Hizo las cosas mucho más rápido que antes.

Mi caso particular (Mac) fue que edité info.plist para usar java 1.7 * (por cualquier razón), y funcionó como un perro absoluto.

Volvió a 1.6 * e instaló java 1.6, y fue rápido.

Estaba enfrentando un rendimiento lento con Intellij 2016.1 (64 bits) y JDK 1.8 (64 bits). Me cambié a

• 64 bits intellij
• 64 bits Java 8 como ruta JAVA_HOME (esto es necesario para ejecutar Intellij de 64 bits)
• Java 8 de 32 bits como JDK para usar en proyectos de Intellij (Archivo -> Estructura del proyecto | Configuración del proyecto -> Proyecto | SDK del proyecto).

Con esta combinación, ahora el rendimiento de Intellij está bastante bien.

Editar el archivo idea.vmoptions es solo una solución temporal hasta la próxima actualización del producto. Consulte las páginas de ayuda de JetBrains para obtener una solución más permanente para establecer estos valores a través de la configuración de VM: https://www.jetbrains.com/help/idea/tuning-the-ide.html

Aumente el tamaño del montón para el compilador. Por defecto, el valor es 700m, que es demasiado pequeño con un número creciente de complementos.

En v2019.1 se encuentra aquí:

Configuración -> Compilación, ejecución, implementación -> Compilador -> Tamaño del almacenamiento dinámico del proceso de compilación (Mbytes)

Después de poner 4000 allí, resolvió la mayoría de mis problemas de rendimiento.

Mi caso particular: tuve una cantidad de method breakpointstiempo mientras ejecutaba mi código en modo de depuración, lo que hizo que mi intelliJ fuera más lento.