Eclipse и IntelliJ являются двумя конкурирующими IDE в отрасли. В социальных сетях и форумах идет много страстных дискуссий, чтобы объявить победителя в этой гонке. Мы подумали, что было бы интересно изучить, какая среда IDE эффективно использует память?
Изучение
Для проведения этого исследования мы использовали Eclipse Java EE Oxygen Release Milestone 2 (4.7.0 M2) и IntelliJ IDEA 2018.2.4 (Ultimate Edition). Обе IDE работали на Java 8.
Чтобы провести это исследование эффективно, мы хотели активировать различные функции IDE. Таким образом, мы закончили тем, что создали простой проект Java. В этом проекте мы создали страницу JSP, класс Manager, класс DAO, который будет записывать и читать записи из базы данных MySQL. Мы писали исходный код, компилировали его, запускали модульные тесты для проверки поведения. На это у нас ушло 1 час 45 минут. Мы провели одно и то же упражнение как в Eclipse, так и в IntelliJ IDE.
Как изучить эффективность памяти?
Один из лучших способов изучения поведения памяти в приложении — это анализ активности сборки мусора. Действия по сбору мусора четко показывают схему использования памяти, скорость создания объекта, скорость восстановления объекта, время паузы при сборке мусора и другие связанные с памятью детали в нирване.
Как изучить деятельность по сбору мусора?
Действия по сбору мусора можно изучить, включив журналы сбора мусора и используя правильные инструменты для анализа журналов сбора мусора. Журналы сбора мусора можно включить, передав следующие аргументы JVM:
1
2
3
4
5
|
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:{GC-log-file-path} |
Для этого упражнения мы использовали инструмент GCeasy для анализа журналов сбора мусора.
В папке, где установлен Eclipse, находится файл eclipse.ini. Его содержимое выглядело так:
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
|
-startup plugins/org.eclipse.equinox.launcher_1. 3.200 .v20160914- 0716 .jar --launcher.library plugins/org.eclipse.equinox.launcher.win32.win32.x86_64_1. 1.400 .v20160914- 0716 -product org.eclipse.epp. package .jee.product --launcher.defaultAction openFile -showsplash org.eclipse.platform --launcher.defaultAction openFile --launcher.appendVmargs -vmargs -Dosgi.requiredJavaVersion= 1.8 -XX:+UseG1GC -XX:+UseStringDeduplication -Dosgi.requiredJavaVersion= 1.8 -Xms256m -Xmx1024m |
В нижней части этого файла мы добавили следующие аргументы, чтобы включить журналы сбора мусора в Eclipse IDE.
1
2
3
4
5
|
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:D:\my_workspace\logs\eclipse-gc.log |
В папке, где установлен IntelliJ, вы увидите файл idea64.exe.vmoptions. Его содержимое выглядело так:
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
|
-Xms256m -Xmx1024m -XX:ReservedCodeCacheSize=240m -XX:+UseConcMarkSweepGC -XX:SoftRefLRUPolicyMSPerMB= 50 -ea -Dsun.io.useCanonCaches= false -Djava.net.preferIPv4Stack= true -Djdk.http.auth.tunneling.disabledSchemes= "" -XX:+HeapDumpOnOutOfMemoryError -XX:-OmitStackTraceInFastThrow |
В нижней части этого файла мы добавили следующие аргументы, чтобы включить журналы сбора мусора в IntelliJ IDE.
1
2
3
4
5
|
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:D:\my_workspace\logs\intellij-gc.log |
ПРИМЕЧАНИЕ. По умолчанию начальный размер кучи IntelliJ сохраняется равным 128 МБ, а максимальный размер кучи — 750 МБ. Принимая во внимание, что начальный размер кучи Eclipse был установлен равным 256 МБ, а максимальный размер кучи — 1024 МБ. Таким образом, чтобы сравнить яблоки с яблоками, мы увеличили начальный размер кучи IntelliJ до 256 МБ, а максимальный размер кучи — до 1024 МБ.
Сравнение поведения памяти
По завершении нашего 1-часового и 45-минутного упражнения мы загрузили файл журнала сбора мусора, сгенерированный обеими IDE, в инструмент GCeasy. Ниже приведены подробные аналитические отчеты, сгенерированные инструментом. Мы рекомендуем вам взглянуть на отчет:
Ниже приведены ключевые наблюдения из аналитического отчета GC:
# 1. Скорость создания объекта
Очевидно, Eclipse создал очень небольшое количество объектов по сравнению с IntelliJ. Eclipse IDE создавал объекты со скоростью 2,41 МБ / с , тогда как IntelliJ создавал объекты со скоростью 69,65 МБ / с (что в 29 раз больше, чем в Eclipse). За весь цикл Eclipse создал только 15,19 ГБ , а IntelliJ создал 430,2 ГБ объектов. Поскольку было создано больше объектов, потребление ресурсов ЦП также было выше при использовании IDE IntelliJ.
# 2. GC Pause Time
На определенных этапах сборки мусора все приложение приостанавливается. По-видимому, среднее время паузы ГХ в Eclipse составляет 33 мс, а максимальное время паузы ГХ составляет 340 мс . С другой стороны, среднее время паузы ГХ IntelliJ составляет всего 8 мс, а максимальное время паузы ГХ составляет 270 мс . Таким образом, с точки зрения GC Pause IntelliJ сравнительно лучше. Несмотря на то, что скорость создания объектов в IntelliJ выше, его среднее время паузы сравнительно лучше, чем в Eclipse, благодаря лучшей настройке ГХ, выполненной в IntelliJ.
# 3. Пропускная способность GC
Пропускная способность GC — это, в основном, количество времени, которое ваше приложение тратит на обработку транзакций клиента по сравнению с количеством времени, которое ваше приложение тратит на сборку мусора. В нашем исследовании пропускная способность Eclipse составляет 99,924%, а пропускная способность IntelliJ — 99,146% . Пропускная способность Eclipse GC лучше, чем пропускная способность IntelliJ.
# 4. GC Алгоритм
Одна из основных причин задержки GC зависит от алгоритма и настроек сборки мусора. Eclispe был настроен для работы с алгоритмом GC GC , тогда как IntelliJ был настроен для работы с алгоритмом CMS GC . Учитывая, что Eclipse создает гораздо меньше объектов, при правильной настройке GC, мы считаем, что время паузы Eclipse GC может быть дополнительно уменьшено.
# 5. System.gc () вызовы
Очевидно, Eclispe IDE явно выполняет вызовы System.gc (). Если в этом нет необходимости, не рекомендуется использовать System.gc () из приложения, так как это мешает работе JVM GC. Непонятно, почему Eclipse IDE явно выполняет вызовы System.gc ().
Вывод
Основываясь на этом ограниченном исследовании, которое мы провели, мы можем сказать, что Eclipse IDE эффективнее по памяти, чем IntelliJ, поскольку для выполнения того же объема работы IntelliJ создает в 29 раз больше объектов, чем Eclipse. С другой стороны, время пауз IntelliJ сравнительно лучше, чем Eclipse. Конечно, мы считаем, что выбор IDE не должен основываться на эффективности памяти. Он должен основываться на наборе функций, пользовательских предпочтениях и критериях производительности.
Смотрите оригинальную статью здесь: Эффективное использование памяти: Eclipse vs IntelliJ (Android Studio) Мнения, высказанные участниками Java Code Geeks, являются их собственными. |