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

208

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?

Jee Seok Yoon
fuente
44
si sigue teniendo problemas de rendimiento reproducibles, infórmelos como se describe aquí: intellij-support.jetbrains.com/entries/… ¡ Gracias de antemano!
Yann Cébron
1
Ahora que lo pienso, el tamaño del montón podría haber sido el problema. Sin embargo, el hecho de que IntelliJ 12 con la configuración predeterminada funciona bien aún permanece. No he usado IntelliJ 13 durante bastante tiempo, así que tendré que verificar esto más tarde.
Jee Seok Yoon
1
Quizás relacionado, quizás no: al menos una vez, cuando experimenté que IntelliJ se ejecutaba particularmente lento, noté que coincidía con una E / S extremadamente alta. Limpiar su caché solucionó el problema. Sospecho que algo en el caché se corrompió y el IDE no lo estaba haciendo bien.
Mike Strobel
1
simplemente limpiar la caché y reiniciar también funcionó para mí. Archivo -> Invalidates Caches ... en intellij 14
demian
1
Esta pregunta está fuera de tema.
alquitrán el

Respuestas:

252

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

Jason D
fuente
19
Gracias Jason ... Esto parece haber hecho el truco para mí. Incrementar el almacenamiento dinámico incluso solo a 2 GB (-Xmx2048m) fue suficiente para ver un aumento significativo en el rendimiento.
Carl Karawani
3
Tengo un total de 8 GB de RAM y cambiar a -Xms512m -Xmx850m -XX: MaxPermSize = 1024m no funcionó para mí.
coding_idiot
2
En ese caso, ¿Has probado con -Xmx4096? También es posible que desee probar valores como -Xmx2048 o -Xmx3192 Como señaló @CarlKarawani, incluso un aumento de 2GB parece ser suficiente para aumentar el rendimiento.
Jason D
2
Tiene sentido, parece ser diferente dependiendo de la máquina también.
Jason D
77
MaxPermSizese ignora desde Java 8.
user2418306
46

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.

Nathan
fuente
3
Eliminé todos los complementos que no uso, o que probablemente no necesite en el corto plazo (por ejemplo, soporte para Mecurical, internacionalización, etc.). Tomó el tiempo de inicio de literalmente MINUTOS, a unos 10-15 segundos). El rendimiento general parece ser mucho más ágil ahora también. Por extraño que parezca, la huella de la memoria no cambió mucho, en mi caso, se mantuvo alrededor de 820 MB.
sean.boyer
44
La desactivación del complemento de subversión redujo mi CPU del 100% a menos del 2%. Si su IntelliJ 13 es lento, probablemente sea un complemento, esta debería ser la respuesta aceptada.
favor,
25

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.

marca
fuente
1
Te recomiendo que dispares un error al rastreador de errores oficial de JetBrains y adjuntes una instantánea de la CPU .
LoKi
2
Desactivar la integración de git e ideavim mejoró significativamente el rendimiento para mí. ¡Gracias!
Hari Menon
Cambié la configuración de memoria y deshabilité la integración de Git. Antes de que el editor de HTML era terriblemente lento en un proyecto moderadamente grande, contemplé tirar el ordenador por la ventana, pero esto parecía para fijarlo en su lugar :)
Richard G
Apagué los complementos relacionados con git y VCS, y ahora estoy en paz.
Sanjay Verma
Octubre de 2017 registrando aquí. Esto todavía parece ser un problema importante. Acabo de desactivar la integración de Git y vi un aumento de velocidad masivo.
irracional
14

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.

paul-g
fuente
3
Esto fue de gran ayuda para mí en Ubuntu 14.04
Charney Kaye
2
Volver a 1.7 hizo que 13.1 funcione mucho mejor en Ubuntu 14.04. ¡Gracias!
pingw33n
Las versiones más recientes de IntelliJ ya están incluidas en Java 8: intellij-support.jetbrains.com/hc/en-us/articles/… y las versiones anteriores no son compatibles. También consulte: stackoverflow.com/questions/8382641/…
Christian Vielma
13

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!

significa
fuente
No parece haber una solución proporcionada aquí: youtrack.jetbrains.com/issue/IDEA-118529#comment=27-656874 Crédito: Tavis Elliott
tmeans
8

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)
Jochen Bedersdorfer
fuente
(OSX 10.9) Esto redujo el uso de mi CPU mucho más que cambiar las opciones de VM. Desearía poder votar esto varias veces.
favor
1
Te recomiendo que dispares un error al rastreador de errores oficial de JetBrains y adjuntes una instantánea de la CPU .
LoKi
6

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
Dogan Eren
fuente
5

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.

Dennis
fuente
5

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.

DanT
fuente
4

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.

jonathanChap
fuente
3

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 .

sorencito
fuente
Tuve el mismo problema en Mac. Es mucho más rápido después de cambiar JVM de 1.6 * a 1.7 * en la lista de información de IntelliJ.
Lei Zhao
2

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.

ktamlyn
fuente
0

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

Ingeniero de software
fuente
1
No, esto no es así ... Tengo exactamente los mismos problemas con las pausas largas, especialmente durante el guardado de archivos, el cambio del editor a un archivo diferente y la activación del marco. Sucede en proyectos de todos los tamaños y los mismos proyectos estaban bien con 12.1.
samkass
1
Parece que puede ser recolección de basura, interrupciones por parte del sistema operativo o un error en Idea. Creo que esto último, aunque es bastante posible, es poco probable porque estoy usando la última versión en un macbook pro bastante potente, junto con media docena de otras personas que hacen lo mismo, y realmente no estamos teniendo estos problemas. aunque lo hicimos cuando no teníamos suficiente RAM. Tuvimos que actualizar nuestras máquinas a 16 GB para darle al sistema operativo suficiente memoria de reserva para trabajar. Estábamos usando toda la memoria libre para Idea, una VM que contiene Oracle y un servidor Jboss.
Ingeniero de software
Quizás, obviamente, debería actualizar idea64.vmoptions si está utilizando un sistema operativo de 64 bits, e idea.vmoptions si está utilizando un sistema operativo de 32 bits.
nrobey
0

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.

Aditya Satyavada
fuente
0

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.

usuario3769865
fuente
0

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.

Omkar
fuente
0

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

James
fuente
0

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.

Volodymyr Zubariev
fuente
0

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.

Deepak Patankar
fuente