Почему IntelliJ 13 IDEA так медленно после обновления с версии 12?

При использовании IntelliJ 13 Ultimate Edition в течение недели это кажется очень медленным.

Прежде всего, вся IDE останавливается на секунду или около того каждый раз. Автоматический запуск Java-редактора очень медленный по сравнению с 12 версиями.

Я ничего не изменил из настроек по умолчанию, кроме использования темы Dracula.

Кажется, что это не проблема моей собственной. Многие люди предложили установить размер кучи выше, чем по умолчанию, или очистить кеш, но я не проверял или не тестировал это предложение. Мне нужно изменить некоторые настройки, чтобы улучшить производительность новой версии?

ОТВЕТЫ

Ответ 1

У меня была та же проблема с медленностью в IntelliJ 13 после обновления с 12. Что для меня работало, это редактирование идеи64.vmoptions в папке bin и установка максимальной кучи на 8 ГБ (было 512 МБ), а Max PermGen - не менее 1 ГБ (было 300 МБ). Пример ниже:

-Xms128m
-Xmx8192m
-XX:MaxPermSize=1024m

После перезагрузки он был намного быстрее.

На Mac этот файл находится по этому пути: /Users/yourusername/Library/Preferences/IntelliJIdea13/idea.vmoptions

Для IntelliJ 14 или 15 на Mac /Applications/IntelliJ IDEA 14.app/Contents/bin/idea.vmoptions

Для IntelliJ 2016, 2017 или выше на Mac /Applications/IntelliJ IDEA.app/Contents/bin/idea.vmoptions

Обновление IntelliJ 2017, похоже, вернет это изменение, поэтому вам может потребоваться повторно применить его после обновления.

В Ubuntu Linux этот файл находится по этому пути относительно каталога установки:

idea-IU-135.475/bin/idea64.vmoptions

и для 2016.2:

 ~/.IdeaIC2016.2/idea64.vmoptions

В Windows 10 (версия сообщества, показанная здесь) эти файлы находятся в:

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

Ответ 2

Я заметил, что отключение многих подключаемых модулей действительно помогает ускорить IntelliJ. Например, я не разрабатываю приложения для Android. Превращение плагинов, связанных с разработкой Android, ускоряет время загрузки и делает программу более плавной на моей машине.

Ответ 3

В моем случае интеграция GIT, по-видимому, вызывает у редактора неудобное замедление с 13.

При вводе, даже комментариев, при включении интеграции GIT, после примерно 30 символов пользовательский интерфейс зависает на секунду или около того. Его обычно не долго, но очень раздражает.

Я использую GIT 1.7.8.0. Работает на Windows 7 64 с твердотельным накопителем и 12 гигабайтами RAM и Intel I7 с 8 процессорами. Я пробовал разные вещи, например, обновляя idea64.exe.vmoptions, чтобы использовать больше памяти, например -Xmx2400m и -XX: MaxPermSize = 2400m, -XX: ParallelGCThreads = 6, но это не устранило проблему.

Репозиторий GIT - это 1.3 гигабайта с 65 000 файлов.

Я создал новый проект "grails" в новом репозитории GIT, и проблем нет. Я создал новый проект grails в существующем большом хранилище GIT, а intellij медленный. Я отключил интеграцию GIT, открыв диалог настроек проекта и удалив корень GIT, и проблема исчезнет.

Я попытался отключить все фоновые операции GIT через 13 пользовательских интерфейсов, но это не повлияло. Я также пробовал как GIT встроенный, так и собственный режимы, и это не имело никакого значения.

В моем случае, как правило, обходной путь заключается в отключении интеграции GIT, пока он мне не понадобится, и затем просто повторно добавьте корень GIT. Если кто-то еще может проверить ту же проблему, мы можем сообщить об этом как проблему.

Ответ 4

В моем случае массовая деградация производительности была вызвана IntelliJ непреднамеренно с использованием JDK/JRE 1.8. Это, по-видимому, очень плохо влияет на производительность рендеринга, а также приводит к неожиданным сбоям и тупикам.

Это сделало бы IDE непригодным (латентность 1-2s для операций) даже для небольшого проекта ~ 3KLOC.

Просто убедитесь, что вы используете JDK/JRE 1.7 при запуске intellij:

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

(или что-то еще эквивалентное для вашей ОС)

Вы можете проверить JRE, который используется для запуска intellij в Справке → О программе → JRE.

Ответ 5

Ну, я не могу ответить на сообщение инженера Dollery выше, потому что у меня еще нет репутации 50... но я заметил то же самое. Одна проблема уже сообщалась в отношении hg4idea: http://youtrack.jetbrains.com/issue/IDEA-118529.

Пока нет исправления, кроме как отключить плагин hg4idea. Но если это окажется вашей проблемой, проголосуйте за ошибку!

Изменить: JetBrains исправил ошибку в сборке IU-138-815!

Ответ 6

У меня была аналогичная проблема. В этом случае это был подключаемый модуль Subversion. (Mac Mavericks, версия SVN 1.7.10) Как только я отключил этот IntelliJ, он снова стал использоваться.

Получил это из 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)

другой запуск:

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

Ответ 7

Лучший опыт работы со следующими опциями (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

Ответ 8

75s → 10s intellij startup. Все, что я сделал, это перейти от использования 32bit EXE по умолчанию к использованию 64-битного exe.

Ответ 9

Для меня проблема была в папке nodes_modules с более чем тысячей файлов. Я должен был пометить каталог как исключенный.

Также см. этот список возможных проблем.

Ответ 10

Я нахожусь на 13.1, и я нашел, что следующие настройки меняют чудеса для меня: Настройки IDE → Редактор → Задержка автозапуска (ms), которую я установил для 1500 (по умолчанию 300).

В большом проекте компилятор и инспекции будут постоянно запускаться между взаимодействиями. Задержка, возможно, помогает уменьшить давление кучи и, как правило, делает весь опыт намного быстрее. Мой процессор намного круче, что, вероятно, помогает.

Ответ 11

Я решил проблемы с производительностью, переключившись на 32-битный режим. Кажется, это связано с JRE, с которым работает IntelliJ. Он поставляется с 32-разрядным 1,7 JRE, который используется при запуске idea.exe. Если вы запустите idea64.exe, он использует 64-битную JRE, установленную в системе. В моем случае это был 1,6 JDK (тот, который я использую для разработки). Это заставило IntelliJ быть почти непригодным для использования.

После установки правильного 64-разрядного 1,7 JDK все было в порядке с 64-разрядным режимом.

См. ответ на веб-сайте IntelliJ Support.

Ответ 12

В моем случае я развиваюсь в Moodle, который создает огромные JS и CSS мини файлы. Как только я excluded тезисы "кэшируют" мини файлы из проекта, InitelliJ запускается нормально снова.

Ответ 13

У меня были похожие проблемы с очень медленными проблемами запуска и кучи, увеличение VM не имело большого значения, просто отсрочка неизбежного, исправление для меня заключалось в том, чтобы сделать недействительным кеш через File > InvalidateCaches/Restart.

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

Ответ 14

Я использую 13 с ранней бета-версии, и у меня нет никаких проблем. Возможно, это ваши конкретные настройки. Может быть, ваш проект со временем вырос, и память, которую вы дали Идеи изначально, для этого сейчас недостаточна? Попробуйте дать идее больше памяти для работы с: http://www.jetbrains.com/idea/webhelp/increasing-memory-heap.html (инструкции о том, как это сделать).

Ответ 15

IntelliJ версия 13 заметно медленнее, чем 12 версия из моего опыта. Есть несколько способов ускорить его, например, увеличить параметры виртуальной машины для IntelliJ. Напр. Я использую проект maven, и для этого я увеличил параметры бегуна и импортера до 4 ГБ. Это делало вещи намного быстрее, чем раньше.

Ответ 16

В моем конкретном случае (Mac) я редактировал info.plist, чтобы использовать java 1.7 * (по какой-либо причине), и он работал как абсолютная собака.

Изменен на 1.6 * и установлен java 1.6, и он был быстрым.

Ответ 17

Я столкнулся с медленной производительностью с Intellij 2016.1 (64-разрядная версия) и JDK 1.8 (64-разрядная версия). Я переключился на

  • 64-битная intellij
  • 64-битная Java 8 как путь JAVA_HOME (требуется для запуска 64-разрядного Intellij)
  • 32-разрядная Java 8 как JDK для использования в проектах Intellij (Файл → Структура проекта | Настройки проекта → Проект | Проект SDK).

В результате этой комбинации производительность Intellij вполне удовлетворительная.

Ответ 18

Редактирование файла idea.vmoptions является временным решением до следующего обновления продукта. См. Страницы справки JetBrains для более постоянного решения для установки этих значений через настройки vm - https://www.jetbrains.com/help/idea/tuning-the-ide.html

Ответ 19

Увеличьте размер кучи для компилятора. По умолчанию это значение 700 м, что слишком мало с увеличением количества плагинов.

На v2019.1 он находится здесь:

Настройки → Сборка, Выполнение, Развертывание → Компилятор → Размер кучи процесса сборки (МБ)

После того, как я поставил 4000, это решило большинство проблем с производительностью.

Ответ 20

У меня была такая же проблема на моем Mac. Тогда я узнал это решение Это решило мою проблему. Он говорит, что это потому, что JVM занимает много времени, чтобы разрешить IP-адрес для localhost. Затем он показывает, как на Mac. Если раньше он строил проект за 35 секунд, то теперь на то же действие уходит 5 секунд.