https://kotlinlang.org logo
Title
v

ValV

12/08/2018, 1:35 PM
Есть ли вероятность, что в будущем IDEA будет работать не на JVM, а нативно в Виндоуз/Линукс? Я просто представил, насколько бы улучшилась производительность/быстродействие среды, а то на ноутбуке часто приходится поглядвать на % использования ОЗУ
g

gildor

12/08/2018, 3:10 PM
я очень в этом соневаюсь, это же гигантский проект, даже если его переписать целиком на Kotlin (что очень далеко как я понимаю от истины) полностью на JVM, в том числе UI
Не говоря уже о том, что все это крайне сомнительно про то что улучшится производительсность сама по себе
1
v

ValV

12/08/2018, 3:38 PM
А есть способы "облегчить" среду настройкой? Отключить всё, кроме самого необходимого?
e

elizarov

12/08/2018, 3:49 PM
Выключение ненужных plugins помогает
v

ValV

12/08/2018, 4:12 PM
А включенные плагины потребляют память, если не используются? Например Scala, JUnit, Groovy, GitHub, и т. д.
Включил индикатор внизу использования памяти: ~300-400 Мб из возможных 730 (в настройке
idea.vmoptions
), но на деле съедает все 3 Гб и начинает выгружать страницы в своп
g

gildor

12/08/2018, 4:16 PM
не исключено конечно и что какой то из плагинов течет или еще какой баг, но это же комплексный проудкт, нужно конкретные кейсы смотреть
e

elizarov

12/08/2018, 4:16 PM
Многие плагины потребляют память, даже если не используются.
v

ValV

12/08/2018, 4:21 PM
Ага, про индексы понял. А они со временем только "разрастаются"?
e

elizarov

12/08/2018, 4:22 PM
По разному. Обычно они постепенно занимают всю выделенную память — это кэш. Когда помять заканчивается — выгружаются (чтобы быть подчитанными с диска при необходимости)
Может чего-то течь. На очень больших проектах бывало что со со временем всё умирает. Но последние годы я такого не замечал. Я неделями порой IDE не перезагружаю. Следить сколько она занимает памяти это занятие примерной такой же полезности как вникать в то, сколко памяти windows в данный момент заняло под дисковый кэш.
v

ValV

12/08/2018, 4:34 PM
Насколько я понял, в Линуксе не существует эффективного механизма дефрагментации памяти, т. е. если куча процесса разрастается и выгружается в своп. Firefox в этом вопросе рекомендуют чаще перезапускать браузер. Перезапуск периодически IDE несколько болезненный из-за переиндексации
e

elizarov

12/08/2018, 4:36 PM
Там есть верхний предел размера куче. Задатеся в idea.vmoptions. Обычно хватает 2-4Gb.
На компе с 16Gb памяти под IDEA не жалко и 4 Gb выделить, если в программировании и заключатеся основная работа
v

ValV

12/08/2018, 4:37 PM
-Xmx
? Это для JVM?
e

elizarov

12/08/2018, 4:37 PM
Да
v

ValV

12/08/2018, 4:38 PM
А это вообще весь максимум для IDE, или это только для компиляции проекта, а плагины как-то обходят это ограничение?
e

elizarov

12/08/2018, 4:39 PM
Это максимум для всего IDE. Там что-то храниться за пределами кучи, но это не очень много.
Что-то работает в отдельных процессах. Обычно всякие демоны (типа gradle или kotlin compiler), но у них свои пределы, обычно не очень большие
v

ValV

12/08/2018, 4:49 PM
А возможна ли такая архитектура среды, при которой все плагины работали бы как отдельные процессы? Тогда, полагаю, управление ими перекладывалось на плечи ОС, тогда бы меньше фрагментация ОЗУ была бы (как мне кажется), и спящие плагины могли бы выгружаться в своп надолго и, возможно, не нагружать память
g

gildor

12/08/2018, 4:52 PM
что-то не уверен что это сильно помогает бразуерам в плане потребления ОЗУ, у которых похожая архитектура (но по другой причине, что бы изолировать разные вкладкии и плагины)
к тому же накладные расходы на множество процессов намного выше, не говоря о том что память так просто не расшаришь, как результат общего кеша в памяти не добится и возможно просто будет намного больше дублирующихся данных в памяти
v

ValV

12/08/2018, 4:54 PM
Хмм. Ну да, это точно. Но в браузеры же напихивают кучу интерактивных элементов и медиа контента
g

gildor

12/08/2018, 4:54 PM
а в IDE нет? Там много графики тоже Хотя это все равно достаточно индеферентно к медиа
e

elizarov

12/08/2018, 4:55 PM
У браузеров закладки очень независимы. А в IDE все плагины работат над общим проектом в общей памяти
v

ValV

12/08/2018, 5:01 PM
Хмм. Теперь понятно. Вряд ли будет IDEA под нативные платформы в виду целесообразности. Хотя, быть может, есть какие-то другие "за" кроме возможного улучшения быстродействия?
g

gildor

12/08/2018, 5:41 PM
нативный UI потенциально может быть полезен, что бы с ним работать полезно иметь нативный язык, но это здоровый проект конечно. Не консистентность UI между платформами наверное все же не есть гуд, даже если это выглядит и работает лучше чем Swing
v

ValV

12/08/2018, 5:47 PM
Нативный язык типа C++? Я так понимаю, речь не идёт о Kotlin-Native, т. к. он для LLVM?
С GUI да, проблема. Хоть Gtk и хвастаются, что библиотеки кроссплатформенные, но как-то в Виндоуз не особо пользуются
v

voddan

12/08/2018, 7:33 PM
У меня Идея глючила на жестком диске, требовался "разогрев" для подгрузки классов. На ССД тормозов нету
g

gildor

12/09/2018, 12:43 AM
Нативный язык типа C++? Я так понимаю, речь не идёт о Kotlin-Native, т. к. он для LLVM?
Ну условно любой язык компилирующийся в бинарники с интеропом с системным UI, будь то C++ или K/N У вас какое то не верное представление об LLVM, от этого язык не становится менее нативный, это по сути абстракция для компиляторов и через LLVM точно так же C и C++ компилируют, через clang вон на Маке все через clang скомаилировано
g

ghedeon

12/15/2018, 8:59 AM
тут правильно заметили: очень вероятно, что ничего не улучшилось бы от слова совсем. "Быстрота" С++ по сравнению с JVM вроде как почти миф уже, нет? Можно тут, в классике почитать: https://notendur.hi.is/snorri/097111-97/tjava.pdf (стр. 573). Книга про java, правда, take it with a grain of salt 😉
v

ValV

12/15/2018, 10:05 AM
Быстрота... А как насчёт эффективности использования памяти?
g

ghedeon

12/15/2018, 11:48 AM
так там весь абзац о том, что java эффективнее использует кучу. Если я правильно понял, Си быстро создает объекты в стеке, но фрагментирует память в куче, а java (благодаря GC) эффективнее в этом плане. По честному, это все красиво на серваке, где накладными расходами на jvm можно пренебречь.
v

ValV

12/15/2018, 12:42 PM
Как происходит выделение памяти для кучи JVM? В смысле на уровне ОС, при помощи тех же
malloc
и
realloc
? JVM во время работы уменьшает используемую процессом память? Если не ошибаюсь, GC запускается только, когда возникает необходимость (выделить память для нового объекта), нет? А если память, используемая JVM по умолчанию только увеличивается, то при нехватке ОЗУ для других процессов, страницы (самого процесса JVM со всеми его внутренними виртуальными стэками и кучами) должны выгружаться в своп? Алгоритмы выгрузки страниц в подкачку, как я понял, зависят от ОС, но, как правило, выгружаться должны те, к которым меньше всего идёт обращение. А если он (процесс) примерно одинаково часто обращается ко всем частям своей памяти (процесса), то страницы будут постоянно подгружаться/выгружаться, что приведёт к снижению отзывчивости системы в целом (или тотальный непрерывный своп-затор)
g

ghedeon

12/15/2018, 8:40 PM
можно написать все это, а можно прочесть уже наконец оригинал. Иначе беспредметно, я пересказывать не буду. Думаю, тредику не жить 😉.
v

ValV

12/16/2018, 1:48 AM
Ну да, в беспредметности обвинить намного проще... В "оригинале" про подкачку говорится только в связи с моделью неограниченной памяти (какой она предстаёт для программиста, которому не нужно заботиться об управлении памятью). Про преимущества в производительности (скорости выделения памяти для новых объектов в куче) говорится лишь для "стабилизировавшейся программы", когда не происходит интенсивного создания/удаления объектов. Это если измерять "эффективность работы с памятью" только лишь скоростью выделения памяти для новых объектов. Ну хорошо, есть ещё момент с "уплотнением" адресного пространства памяти, когда "выжившие" данные копирутся в начало (для stop-and-copy), но это происходит не всегда, а mark-and-sweep ничем не лучше фрагментации при "обычном" выделении памяти в C++. Как подсказывает Всезнающий, JVM лишь может быть немного эффективнее при создании большого количества мелких объектов, если программист C++ не использовал memory pool allocator. Во всех остальных случаях заявления о том, что JVM может быть эффективнее кода, написанного на том же C++ больше похожи на вброс. Даже при фрагментации памяти, думаю, адресное пространство пространство программы C++ не намного увеличится из-за того, что небольшие фрагменты вначале таки будут заполняться соответсвенно небольшими объектами (это моё предположение, нужны фактические подтверждения, как и того, что JVM быстрее C++). Вопрос ещё в том, что JVM потом ещё будет всю память последовательно проходить несколько раз для разных этапов сборки мусора, что только снизит скорость по сравнению с однопроходным алгоритмом поиска свободного места в куче (зато не надо самому удалять). И третий момент, на счёт которого "оригинал" не даёт однозначного ответа: "какова эффективность JVM при нехватке свободной физической памяти по сравнению с программой, написанной на том же _C++_" (если уж стали ссылаться на C++ как на эталон эффективности). ОС ничего не знает о сборщике мусора в JVM, т. е. может выгрузить в своп любую часть адресного пространства JVM. Тут ещё сборщик мусора, которому может "захотеться" сделать stop-and-copy на выгруженных в своп страницах, т. е. он это сделает в любом случае, тогда как некоторые части кучи/стека программы, написанной на C++ могут болтаться в свопе очень долго без ущерба производительности, т. к. к ним не идёт обращение, и для выделения памяти под новые объекты, старые не нужны (лежат себе и лежат в свопе)