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

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

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

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

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

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

-Xms128m
-Xmx8192m
-XX:MaxPermSize=1024m

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

Для IntelliJ 2020 возвращение в 2017 году на Mac /Applications/IntelliJ IDEA.app/Contents/bin/idea.vmoptions

На Mac этот файл находится по следующему пути:

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

Для IntelliJ 13 на Mac /Users/yourusername/Library/Preferences/IntelliJIdea13/idea.vmoptions

Средство обновления IntelliJ (с 2017 года) откатывает это изменение, поэтому вам может потребоваться повторно применить его после обновления.

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

idea-IU-135.475/bin/idea64.vmoptions

и на 2016 год:

 ~/.IdeaIC2016.2/idea64.vmoptions

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

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

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

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

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

Я использую GIT 1.7.8.0. Работает на Windows 7 64 с твердотельным накопителем и 12 гигабайтами оперативной памяти и 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. Если кто-то еще может проверить ту же проблему, мы можем сообщить о ней как о проблеме.

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

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

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

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

(или любой другой эквивалент для вашей ОС)

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

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

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

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

У меня была похожая проблема. В этом случае это был плагин 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)

Лучший опыт работы со следующими параметрами (idea64.exe.vmoptions):

    -server
    -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: + TieredCompilation

    -Djava.net.preferIPv4Stack = верно
    -Dsun.io.useCanonCaches = ложь
    -Djsse.enableSNIExtension = верно
    -ea

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

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

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

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

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

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

После установки надлежащего 64-битного 1.7 JDK все было в порядке и с 64-битным режимом.

Смотрите ответ на веб-сайте поддержки IntelliJ .

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

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

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

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

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

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

Вернулся к 1.6 * и установил java 1.6, и это было быстро.

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

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

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

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

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

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

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

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

Мой конкретный случай: у меня было некоторое method breakpointsвремя, когда я выполнял свой код в режиме отладки, что делало мой intelliJ медленным.