https://kotlinlang.org logo
Join Slack
Powered by
Есть ли вероятность, что в будущем IDEA будет рабо...
# russian
v
Есть ли вероятность, что в будущем IDEA будет работать не на JVM, а нативно в Виндоуз/Линукс? Я просто представил, насколько бы улучшилась производительность/быстродействие среды, а то на ноутбуке часто приходится поглядвать на % использования ОЗУ
g
я очень в этом соневаюсь, это же гигантский проект, даже если его переписать целиком на Kotlin (что очень далеко как я понимаю от истины) полностью на JVM, в том числе UI
Не говоря уже о том, что все это крайне сомнительно про то что улучшится производительсность сама по себе
➕ 1
v
А есть способы "облегчить" среду настройкой? Отключить всё, кроме самого необходимого?
e
Выключение ненужных plugins помогает
v
А включенные плагины потребляют память, если не используются? Например Scala, JUnit, Groovy, GitHub, и т. д.
Включил индикатор внизу использования памяти: ~300-400 Мб из возможных 730 (в настройке 
idea.vmoptions
), но на деле съедает все 3 Гб и начинает выгружать страницы в своп
g
не исключено конечно и что какой то из плагинов течет или еще какой баг, но это же комплексный проудкт, нужно конкретные кейсы смотреть
e
Многие плагины потребляют память, даже если не используются.
v
Ага, про индексы понял. А они со временем только "разрастаются"?
e
По разному. Обычно они постепенно занимают всю выделенную память — это кэш. Когда помять заканчивается — выгружаются (чтобы быть подчитанными с диска при необходимости)
Может чего-то течь. На очень больших проектах бывало что со со временем всё умирает. Но последние годы я такого не замечал. Я неделями порой IDE не перезагружаю. Следить сколько она занимает памяти это занятие примерной такой же полезности как вникать в то, сколко памяти windows в данный момент заняло под дисковый кэш.
v
Насколько я понял, в Линуксе не существует эффективного механизма дефрагментации памяти, т. е. если куча процесса разрастается и выгружается в своп. Firefox в этом вопросе рекомендуют чаще перезапускать браузер. Перезапуск периодически IDE несколько болезненный из-за переиндексации
e
Там есть верхний предел размера куче. Задатеся в idea.vmoptions. Обычно хватает 2-4Gb.
На компе с 16Gb памяти под IDEA не жалко и 4 Gb выделить, если в программировании и заключатеся основная работа
v
-Xmx
? Это для JVM?
e
Да
v
А это вообще весь максимум для IDE, или это только для компиляции проекта, а плагины как-то обходят это ограничение?
e
Это максимум для всего IDE. Там что-то храниться за пределами кучи, но это не очень много.
Что-то работает в отдельных процессах. Обычно всякие демоны (типа gradle или kotlin compiler), но у них свои пределы, обычно не очень большие
v
А возможна ли такая архитектура среды, при которой все плагины работали бы как отдельные процессы? Тогда, полагаю, управление ими перекладывалось на плечи ОС, тогда бы меньше фрагментация ОЗУ была бы (как мне кажется), и спящие плагины могли бы выгружаться в своп надолго и, возможно, не нагружать память
g
что-то не уверен что это сильно помогает бразуерам в плане потребления ОЗУ, у которых похожая архитектура (но по другой причине, что бы изолировать разные вкладкии и плагины)
к тому же накладные расходы на множество процессов намного выше, не говоря о том что память так просто не расшаришь, как результат общего кеша в памяти не добится и возможно просто будет намного больше дублирующихся данных в памяти
v
Хмм. Ну да, это точно. Но в браузеры же напихивают кучу интерактивных элементов и медиа контента
g
а в IDE нет? Там много графики тоже Хотя это все равно достаточно индеферентно к медиа
e
У браузеров закладки очень независимы. А в IDE все плагины работат над общим проектом в общей памяти
v
Хмм. Теперь понятно. Вряд ли будет IDEA под нативные платформы в виду целесообразности. Хотя, быть может, есть какие-то другие "за" кроме возможного улучшения быстродействия?
g
нативный UI потенциально может быть полезен, что бы с ним работать полезно иметь нативный язык, но это здоровый проект конечно. Не консистентность UI между платформами наверное все же не есть гуд, даже если это выглядит и работает лучше чем Swing
v
Нативный язык типа C++? Я так понимаю, речь не идёт о Kotlin-Native, т. к. он для LLVM?
С GUI да, проблема. Хоть Gtk и хвастаются, что библиотеки кроссплатформенные, но как-то в Виндоуз не особо пользуются
v
У меня Идея глючила на жестком диске, требовался "разогрев" для подгрузки классов. На ССД тормозов нету
g
Нативный язык типа C++? Я так понимаю, речь не идёт о Kotlin-Native, т. к. он для LLVM?
Ну условно любой язык компилирующийся в бинарники с интеропом с системным UI, будь то C++ или K/N У вас какое то не верное представление об LLVM, от этого язык не становится менее нативный, это по сути абстракция для компиляторов и через LLVM точно так же C и C++ компилируют, через clang вон на Маке все через clang скомаилировано
g
тут правильно заметили: очень вероятно, что ничего не улучшилось бы от слова совсем. "Быстрота" С++ по сравнению с JVM вроде как почти миф уже, нет? Можно тут, в классике почитать: https://notendur.hi.is/snorri/097111-97/tjava.pdf (стр. 573). Книга про java, правда, take it with a grain of salt 😉
v
Быстрота... А как насчёт эффективности использования памяти?
g
так там весь абзац о том, что java эффективнее использует кучу. Если я правильно понял, Си быстро создает объекты в стеке, но фрагментирует память в куче, а java (благодаря GC) эффективнее в этом плане. По честному, это все красиво на серваке, где накладными расходами на jvm можно пренебречь.
v
Как происходит выделение памяти для кучи JVM? В смысле на уровне ОС, при помощи тех же 
malloc
и 
realloc
? JVM во время работы уменьшает используемую процессом память? Если не ошибаюсь, GC запускается только, когда возникает необходимость (выделить память для нового объекта), нет? А если память, используемая JVM по умолчанию только увеличивается, то при нехватке ОЗУ для других процессов, страницы (самого процесса JVM со всеми его внутренними виртуальными стэками и кучами) должны выгружаться в своп? Алгоритмы выгрузки страниц в подкачку, как я понял, зависят от ОС, но, как правило, выгружаться должны те, к которым меньше всего идёт обращение. А если он (процесс) примерно одинаково часто обращается ко всем частям своей памяти (процесса), то страницы будут постоянно подгружаться/выгружаться, что приведёт к снижению отзывчивости системы в целом (или тотальный непрерывный своп-затор)
g
можно написать все это, а можно прочесть уже наконец оригинал. Иначе беспредметно, я пересказывать не буду. Думаю, тредику не жить 😉.
v
Ну да, в беспредметности обвинить намного проще... В "оригинале" про подкачку говорится только в связи с моделью неограниченной памяти (какой она предстаёт для программиста, которому не нужно заботиться об управлении памятью). Про преимущества в производительности (скорости выделения памяти для новых объектов в куче) говорится лишь для "стабилизировавшейся программы", когда не происходит интенсивного создания/удаления объектов. Это если измерять "эффективность работы с памятью" только лишь скоростью выделения памяти для новых объектов. Ну хорошо, есть ещё момент с "уплотнением" адресного пространства памяти, когда "выжившие" данные копирутся в начало (для 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++ могут болтаться в свопе очень долго без ущерба производительности, т. к. к ним не идёт обращение, и для выделения памяти под новые объекты, старые не нужны (лежат себе и лежат в свопе)
3 Views
Open in Slack
PreviousNext
Powered by