Чому IntelliJ 13 IDEA настільки повільний після оновлення до версії 12?

Хоча користування IntelliJ 13 ultimate Edition протягом тижня, це просто здається дуже повільним.

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

Я нічого не змінив у налаштуваннях за замовчуванням, крім використання теми Dracula.

Здається, це не моя проблема. Багато людей пропонували встановити розмір купи вище, ніж за замовчуванням, або очистити кеш, але я не перевіряв і не перевіряв ці пропозиції. Чи потрібно змінити деякі налаштування, щоб покращити продуктивність нової версії?

У мене була така ж проблема з повільністю в IntelliJ 13 після оновлення з 12. Що для мене працювало, це редагування ідеї64.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.2:

 ~/.IdeaIC2016.2/idea64.vmoptions

У Windows 10 (видання спільноти показано тут) ці файли розміщені у:

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 = 2400м, -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):

    -сервіс
    -Xms1g
    -Xmx3g
    -Xss16m
    -XX: NewRatio = 3

    -XX: ReservedCodeCacheSize = 240м
    -XX: + UseCompressionOops
    -XX: SoftRefLRUPolicyMSPerMB = 50

    -XX: ПаралельніGCThreads = 4
    -XX: + UseConcMarkSweepGC
    -XX: ConcGCThreads = 4

    -XX: + CMSClassUnloadingEnabled
    -XX: + CMSParallelRemarkEnabled
    -XX: CMSInitiatingOccupancyFraction = 65
    -XX: + CMSScavengeBeforeRemark
    -XX: + ВикористовуватиCMSInitiatingOccupancyOnly

    -XX: MaxTenuringThreshold = 1
    -XX: SurvivorRatio = 8
    -XX: + UseCodeCacheFlushing
    -XX: + AggressiveOpts
    -XX: -TraceClassUnloading
    -XX: + ЗавждиPreTouch
    -XX: + багатоярусна компіляція

    -Djava.net.preferIPv4Stack = вірно
    -Dsun.io.useCanonCaches = помилково
    -Djsse.enableSNIExtension = вірно
    -еа

75-х -> 10-х років запуску Intellij. Все, що я зробив, - це перейти з використання 32-бітного EXE за замовчуванням на використання 64-бітного EXE.

Для мене проблемою була папка nodes_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 знову працював нормально.

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

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

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

Моя версія IntelliJ 13 помітно повільніше, ніж версія 12. Існує кілька способів прискорити його, наприклад, збільшити VM варіанти для 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 (Файл -> Структура проекту | Налаштування проекту -> Проект | Проект SDK).

За цією комбінацією тепер продуктивність Intellij цілком нормальна.

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

Збільшити розмір купи компілятора. За замовчуванням значення становить 700 м, що є занадто малим із збільшенням кількості плагінів.

На v2019.1 він розташований тут:

Налаштування -> Збірка, Виконання, Розгортання -> Компілятор -> Розмір купи процесу (Мбайт)

Після того, як я помістив туди 4000, це вирішило більшість моїх питань щодо продуктивності.

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