Единственная и единственная причина для настройки параметров памяти IntelliJ IDEA

Не будь Скруджем и дай своей IDE больше памяти

Вчера у нас была дискуссия о настройке параметров памяти в IntelliJ IDEA, и выяснилось, что некоторые люди этого не делают, некоторые (как я) используют простой набор изменений, а некоторые разработчики создают необычные, сложные настройки, которые удовлетворяют их потребностям. Во время работы над текущим проектом мне приходилось иметь дело с несколькими небольшими проектами в области микросервисов и одним старым проектом, который является довольно крупным бизнесом клиента. И после внесения некоторых изменений я заметил действительно значительное улучшение, когда дело доходит до скорости IDE и отзывчивости. Но в то время я не измерял, что именно изменилось, это было только субъективное наблюдение, что «ИДЕЯ теперь быстрее» .

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

Цель

Мой план состоит в том, чтобы сравнить, как различные настройки памяти IDEA работают в сценарии, близком к моему ежедневному использованию (загрузка большого проекта, загрузка двух или трех микросервисов, обновление большого проекта после гипотетического git pull ), а затем выбрать наиболее оптимальные настройки, когда дело доходит до памяти улучшение потребления и скорости.

Тестовая машина и проекты

Ноутбук : MacBook Pro Retina, 2,3 ГГц Intel Core i7, 16 ГБ 1600 МГц DDR3, SSD-диск, OS X Yosemite

проектов

• Большой проект — монолит, 700 000 строк кода (Java 8 и Groovy), 303 модуля Gradle
• Два микросервиса — небольшие проекты с 10 000 — 20 000 строк кода (Java 8 и Groovy), каждый с одним модулем Gradle

Тестовый сценарий

1. Закрыть все проекты в Idea
2. Проверьте настройки в файле idea.vmoptions
3. Сбросить мой ноутбук
4. После запуска закройте все не связанные программы (коммуникаторы и т. Д.)
5. Открытая идея (измерение времени)
6. Открытый Большой Проект (время измерения)
7. Проверьте jstat -gcutil
8. Откройте еще два проекта: Микросервис Один и Микросервис Два (время измерения)
9. Проверьте jstat -gcutil
10. Вернитесь в Большой проект и нажмите кнопку «Обновить проект Gradle» (измерение времени)
11. Проверьте jstat -gcutil

Что такое jstat -gcutil

jstat — это инструмент, доступный в вашем JDK для мониторинга статистики JVM и сборщика мусора. У него много разных опций для сбора различных данных ( полная документация здесь ), но нас интересует только один: -gcutil :

Пример вывода этой команды выглядит следующим образом:

В этом посте наиболее важными параметрами являются количество событий GC ( YGC и FGC ) и время сбора ( YGCT и FGCT ).

Протестированные настройки

Я протестировал четыре различных параметра, чтобы упростить чтение, каждому из них было присвоено имя.

По умолчанию (серый)

Это встроенные настройки, предоставляемые JetBrains, чистая IDEA 15 использует их:

Большой красный)

4096 МБ для Xmx и 1024 МБ для ReservedCodeCacheSize , это довольно много памяти.

Сбалансированный (синий)

2 ГБ для Xmx и 2 ГБ для Xms, более сбалансированный подход к потреблению памяти

Изысканный (оранжевый)

2 ГБ для Xmx и 2 ГБ для Xms, как указано выше, но указан другой сборщик мусора и много различных флагов для управления ГХ и памятью. Я получил эти настройки от Юрия.

Итак, это наши тестовые настройки. Чтобы выполнить наши тестовые сценарии, мы должны создать файл idea.vmoptions в ~ / Library / Preferences / IntelliJIdea15 / (это зависит от Mac OS, чтобы узнать, как изменить эти настройки для вашей ОС, прочитайте эту статью ).

Теперь пришло время выполнить наши тестовые сценарии и сравнить результаты.

Полученные результаты

Время запуска идеи

Как видите, время запуска не зависит от настроек памяти. Время запуска идеи составляет около 10 секунд для всех тестовых сценариев, независимо от того, сколько памяти мы выделяем. И это не удивительно, так как эти настройки не должны влиять на поведение приложения на такой ранней стадии.

Время загружать Большой проект

Хорошо, теперь пришло время загрузить наш Monolith и его 700 тыс. Строк кода.

Наконец, есть некоторые различия. Настройки по умолчанию работают почти в три раза хуже остальных. Видимо, такая большая кодовая база требует больше памяти 🙂 И если мы выполним

мы заметим, что Garbage Collector был действительно очень занят настройками по умолчанию, когда мы сравним его с другими настройками.

Не только общее время, затрачиваемое GC на освобождение памяти, значительно выше (примерно в 50 раз), но и среднее время выполнения Full GC намного, намного дольше. Длительные периоды, проведенные на Full GC, являются основной причиной низкой отзывчивости нашей IDE.

Открытие двух микросервисов в IDEA

Итак, у нас загружен Monolith, но нам нужно добавить немного кода на два меньших микросервиса. Итак, давайте откроем их в IDEA и сравним общее время.

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

jstat -gcutil снова

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

Завершающий этап: перезагрузите Монолит

Итак, мы написали некоторое время, и теперь нам нужно извлечь последнюю версию The Big Project из репозитория, а затем обновить Gradle Project, чтобы IDEA могла видеть все новые классы и т. Д.

Важное примечание : Бар для настройки по умолчанию настолько высок, потому что во время обновления произошел сбой IDEA, и я не смог измерить фактическое время. Просто назначенной памяти было недостаточно для выполнения этой операции.

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

jstat -gcutil в последний раз

Поскольку IDEA не удалось обновить проект с настройками по умолчанию , они не включены в это измерение.

На этих последних графиках мы видим, что различия между общим временем довольно малы, но один Full GC является самым быстрым с примененными настройками Big . Опять же, похоже, что очень большой Xmx помогает немного больше, когда речь идет об отзывчивости.

Резюме

В этом коротком эксперименте я попытался проверить, сколько мы можем получить, настроив параметры памяти IntelliJ IDEA, и похоже, что даже некоторые простые настройки могут значительно улучшить производительность нашей IDE и ускорить нашу работу. Конечно, чем больше памяти вы выделите, тем лучше будут результаты, но мы используем IDE рядом со многими различными приложениями, которые также потребляют память, поэтому наша цель должна заключаться в том, чтобы найти баланс между повышением производительности и потреблением памяти. Я думаю, что в большинстве случаев наилучшим подходом является установка значения Xmx между 2g и 3g. Если у вас есть больше времени, вы можете поиграть с jstat и jvisualm, чтобы проверить, как изменение различных флагов виртуальной машины влияет на производительность и объем памяти.

А вы?

А что насчет тебя? Какова ваша установка idea.vmoptions? Есть ли у вас другие способы улучшить производительность InteliJ IDEA?