Por que o IntelliJ 13 IDEA é tão lento após a atualização da versão 12?

Ao usar o IntelliJ 13 ultimate edition por uma semana, parece muito lento.

Primeiro de tudo, o IDE inteiro para por um segundo ou mais de vez em quando. A conclusão automática do editor Java é realmente lenta em comparação com a versão 12.

Não mudei nada das configurações padrão, a não ser o uso do tema Drácula.

Parece que este não é um problema meu. Muitas pessoas sugeriram definir o tamanho do heap mais alto que o padrão ou limpar o cache, mas eu não verifiquei ou testei sobre essa sugestão. Preciso alterar algumas configurações para melhorar o desempenho da nova versão?

Eu tive o mesmo problema com lentidão no IntelliJ 13 após a atualização do 12. O que funcionou para mim foi editar as idea64.vmoptions na pasta bin e definir o heap máximo para 8 GB (era 512 MB) e o Max PermGen para pelo menos 1 GB (era de 300 MB) .Exemplo abaixo:

-Xms128m
-Xmx8192m
-XX:MaxPermSize=1024m

Ao reiniciar, era muito mais rápido.

Para IntelliJ 2020, voltando a 2017 no Mac /Applications/IntelliJ IDEA.app/Contents/bin/idea.vmoptions

Em um Mac, esse arquivo está localizado neste caminho:

Para IntelliJ 14 ou 15 no Mac /Applications/IntelliJ IDEA 14.app/Contents/bin/idea.vmoptions

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

O atualizador do IntelliJ (desde 2017) parece reverter essa alteração, portanto, pode ser necessário reaplicá-la após a atualização.

No Ubuntu Linux, esse arquivo está localizado neste caminho em relação ao diretório de instalação:

idea-IU-135.475/bin/idea64.vmoptions

e para 2016.2:

 ~/.IdeaIC2016.2/idea64.vmoptions

No Windows 10 (edição comunitária mostrada aqui), esses arquivos estão localizados em:

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

Percebi que desabilitar muitos plug-ins realmente ajuda a acelerar o IntelliJ. Por exemplo, não estou desenvolvendo aplicativos Android. Desligar os plugins relacionados ao desenvolvimento do Android acelera o tempo de carregamento e torna o programa muito mais suave na minha máquina.

No meu caso, a integração com o GIT parece estar fazendo com que o editor fique frustrantemente lento com 13.

Ao digitar, até mesmo comentar, com a integração do GIT ativada, após cerca de 30 caracteres, a interface do usuário congela por mais ou menos um segundo. Geralmente não é longo, mas muito irritante.

Estou usando o GIT 1.7.8.0. Rodando no Windows 7 64 com uma unidade de estado sólido e 12 GB de RAM e um Intel I7 com 8 CPUs. Tentei várias coisas, como atualizar as idea64.exe.vmoptions para usar mais memória, como -Xmx2400m e -XX: MaxPermSize = 2400m, -XX: ParallelGCThreads = 6, mas não resolveu o problema.

O repositório git é de 1,3 GB com 65.000 arquivos.

Eu criei um novo projeto "grails" em um novo repositório git, e não há problema. Criei um novo projeto grails no grande repositório git existente, e o intellij é lento. Desativei a integração do git abrindo a caixa de diálogo de configurações do projeto e excluindo a raiz do git, e o problema desaparece.

Tentei desativar todas as operações em segundo plano do GIT por meio da 13 UI, mas não fez diferença. Também experimentei os modos interno e nativo do GIT, e não fez diferença.

No meu caso, a solução parece ser desabilitar a integração com o GIT até que eu precise, e depois adicionar novamente a raiz do git. Se alguém puder verificar o mesmo problema, poderemos denunciá-lo como um problema.

No meu caso, a degradação maciça do desempenho foi causada pelo IntelliJ acidentalmente usando o JDK / JRE 1.8. Isso parece afetar muito o desempenho da renderização e também leva a algumas falhas e bloqueios inesperados.

Isso tornaria o IDE inutilizável (latência de 1-2s nas operações), mesmo para um pequeno projeto ~ 3KLOC.

Apenas verifique se você está usando o JDK / JRE 1.7 ao executar o intellij:

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

(ou o equivalente ao seu sistema operacional)

Você pode verificar o JRE que está sendo usado para executar o intellij em Ajuda -> Sobre -> JRE.

Bem, eu não posso responder à postagem do Engineer Dollery acima porque ainda não tenho 50 representantes ... mas notei a mesma coisa. Um problema já foi relatado em relação ao hg4idea: http://youtrack.jetbrains.com/issue/IDEA-118529 .

Ainda não há correção, exceto para desativar o plug-in hg4idea. Mas se esse for o seu problema, vote no bug!

Edit: JetBrains corrigiu o bug na compilação IU-138-815!

Eu tive um problema parecido. Nesse caso, era o plug-in do Subversion. (Mac Mavericks, SVN versão 1.7.10) Depois que eu desabilitei este IntelliJ tornou-se utilizável novamente.

Entendi isso do 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)

outra corrida:

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

Melhor experiência com as seguintes opções (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: + UseCMSInitiatingOccupancyOnly

    -XX: MaxTenuringThreshold = 1
    -XX: SurvivorRatio = 8
    -XX: + UseCodeCacheFlushing
    -XX: + AggressiveOpts
    -XX: -TraceClassUnloading
    -XX: + AlwaysPreTouch
    -XX: + Compilação em camadas

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

Inicialização intellij 75s -> 10s. Tudo o que fiz foi passar do exe padrão de 32 bits para o exe de 64 bits.

Para mim, o problema era uma pasta nodes_modules com mais de mil arquivos. Eu tive que marcar o diretório como excluído.

Veja também esta lista de possíveis problemas.

Estou na 13.1 e achei a seguinte configuração que faz maravilhas para mim: Configurações IDE -> Editor -> Atraso da análise automática (ms), que defini como 1500 (o padrão é 300).

Em um projeto grande, o compilador e as inspeções seriam constantemente iniciados entre as interações. O atraso talvez ajude a reduzir a pressão da pilha e geralmente torne toda a experiência muito mais rápida. Minha CPU também é muito mais legal, o que provavelmente ajuda.

Resolvi meus problemas de desempenho alternando para o modo de 32 bits. Parece estar relacionado ao JRE com o qual o IntelliJ é executado. É fornecido com um JRE 1.7 de 32 bits que é usado ao iniciar o idea.exe. Se você iniciar o idea64.exe, ele utilizará um JRE de 64 bits instalado no sistema. No meu caso, esse foi um JDK 1.6 (o que eu uso para desenvolvimento). Isso fez com que o IntelliJ fosse quase inutilizável.

Depois de instalar um JDK 1.7 de 64 bits adequado, tudo estava bem com o modo de 64 bits também.

Veja a resposta no site de suporte da IntelliJ .

No meu caso, estou desenvolvendo no Moodle, que cria enormes arquivos minificados de JS e CSS. Depois que excludedesses arquivos foram "armazenados em cache" do projeto, o InitelliJ foi executado normalmente novamente.

Eu tive problemas semelhantes com um início muito lento e problemas de heap, o aumento da VM não fez uma grande diferença, apenas atrasou o inevitável, a correção para mim foi invalidar o cache por meio de Arquivo> InvalidateCaches / Restart.

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

Uso 13 desde o início da versão beta e não tenho nenhum problema. Talvez sejam suas configurações específicas. Talvez o seu projeto tenha aumentado com o tempo e a memória que você deu ao Idea originalmente não seja suficiente agora. Tente fornecer ao Idea mais memória para trabalhar: http://www.jetbrains.com/idea/webhelp/increasing-memory-heap.html (instruções sobre como fazer isso).

A versão 13 do IntelliJ é notavelmente mais lenta que a versão 12 da minha experiência. Existem algumas maneiras de acelerar isso, como aumentar as opções de VM para o intelliJ. Por exemplo. Estou usando um projeto maven e, para isso, ampliei as opções de corredor e importador para 4 GB. Isso tornou as coisas muito mais rápidas do que antes.

Meu caso particular (Mac) foi que eu editei o info.plist para usar o java 1.7 * (por qualquer motivo), e ele funcionou como um cão absoluto.

Mudou de volta para 1.6 * e instalou o java 1.6, e foi rápido.

Eu estava enfrentando um desempenho lento com o Intellij 2016.1 (64 bits) e o JDK 1.8 (64 bits). Eu mudei para

• Intellij de 64 bits
• Java 8 de 64 bits como caminho JAVA_HOME (Isso é necessário para executar o Intellij de 64 bits)
• Java 8 de 32 bits como JDK a ser usado para projetos Intellij (Arquivo -> Estrutura do Projeto | Configurações do Projeto -> Projeto | SDK do Projeto).

Com essa combinação, agora o desempenho do Intellij é bastante bom.

A edição do arquivo idea.vmoptions é apenas uma solução temporária até a próxima atualização do produto. Consulte as páginas de ajuda do JetBrains para obter uma solução mais permanente para definir esses valores através das configurações da vm - https://www.jetbrains.com/help/idea/tuning-the-ide.html

Aumente o tamanho do heap para o compilador. Por padrão, o valor é 700m, o que é muito pequeno com o aumento do número de plugins.

Na v2019.1, localizava aqui:

Configurações -> Compilação, Execução, Implantação -> Compilador -> Tamanho do heap do processo de compilação (Mbytes)

Depois de colocar 4000 lá, ele resolveu a maioria dos meus problemas de desempenho.

Meu caso particular: eu tive vários method breakpointsenquanto estava executando meu código no modo de depuração, o que fez meu intelecto lento.