ох уж эти утечки памяти
23.09.2020, 06:37
Чота какое-то странное представление о Яве в этом комиксе.
В реальности она сожрет всю память, которую ей только позволишь аллокейтнуть, даже если она ей нахрен не нужна.
В реальности она сожрет всю память, которую ей только позволишь аллокейтнуть, даже если она ей нахрен не нужна.
Я несколько лет пользовался текстовым редактором jEdit, который, как можно догадаться из названия, написан на Java.
Так вот он ел очень мало памяти.
Так что странное представление у тебя.
А ест много памяти не язык, а программа на языке. И вот с ними у Java действительно проблема. Java провоцирует строить абстракции над абстракциями, что в итоге порождает монстров. Ну а те жрут всё, что жрётся есессно.
Так вот он ел очень мало памяти.
Так что странное представление у тебя.
А ест много памяти не язык, а программа на языке. И вот с ними у Java действительно проблема. Java провоцирует строить абстракции над абстракциями, что в итоге порождает монстров. Ну а те жрут всё, что жрётся есессно.
Жрут память программисты, что пишут такой код. На С++ в 80-х и 90-х на плюсах писали шикарные программы которые не жрали больше одного мегабайта. В Java тоже можно грамотно построить архитектуру, что много памяти не потребуется, и GC не придется удалять 100500 объектов каждые 5 сек.
ну, немножко таки жрёт. Вот экранная линеечка JRuler, минималистичная.
что-то подобное я писал на Delphi в начале 2000, она жрала 400 кб.
если на плюсах её написать - exe будет весить несколько килобайт, а в памяти займёт 20-30 кб.
что-то подобное я писал на Delphi в начале 2000, она жрала 400 кб.
если на плюсах её написать - exe будет весить несколько килобайт, а в памяти займёт 20-30 кб.
толстолис всё же тоньше хрома. в хроме одна вкладка открыта, а в файрфоксе около 300. я на него с хрома перелез потому что хром с 50-ю вкладками все 8 гиг озу выжырал и падал, забирая с собой в вальгаллу фотошоп с апачем.
Ну что тут скажешь писать такие шикарные программы долго и дорого, а кто согласится например на новую часть гта которая будет выходить раз в 20 лет стоить около 200$ но при этом таки мало весить и запускаться практически на любом ведре. Приоритеты поменялись.
Тут стоит уточнить, что мало весить современные игры не могут даже не из-за разъевшегося кода, а из-за хайрезных текстур и прочих детализированных контентов, которые занимают дохрена.
Это понятно, но и их при желании можно почистить и убрать детали на которые никто не обратит внимание, но в общем этим тоже никто заниматься не будет.
Это уже даже не код, а работа художников, моделлеров, левелдизайнеров.
И, с другой стороны, многие как раз ценят мелочи которые на игру напрямую не влияют, но проработаны и работают на восприятие настоящести мира.
И, с другой стороны, многие как раз ценят мелочи которые на игру напрямую не влияют, но проработаны и работают на восприятие настоящести мира.
Тут все-таки имеет значение и реализация рантайм энвайромента.
Я имел в виду то, что Ява Машина, как минимум работающая под линухами, не любит отдавать память, даже если программы работающие под ней давно ее освободили.
Я имел в виду то, что Ява Машина, как минимум работающая под линухами, не любит отдавать память, даже если программы работающие под ней давно ее освободили.
Лучше удалить 100500 и даже 10050000 со сложностью an чем их переиспользовать со сложностью n^2, а то и хуже.
Поясню:
Чтобы экономить память на
java нужно выделять как можно меньше памяти объектам через 'new'. Для этого придётся писать reset методы, которые жрут проц. Если программирование многопоточной (а какое может быть в 2020), то накидывает либо сложность на многопоточную реализацию, любо затраты на оверсинхронизацию. Приправим к этому щепотку нюбства и коллизий данных из-за гонки и получаем, что лучше жрать память и работать нормально, чем её экономить и из-за собственной криворукости страдать от трудных багов, а получить в итоге код, который работает даже медленнее, чем если бы мы не парились про оптимизацию вовсе.
Поясню:
Чтобы экономить память на
java нужно выделять как можно меньше памяти объектам через 'new'. Для этого придётся писать reset методы, которые жрут проц. Если программирование многопоточной (а какое может быть в 2020), то накидывает либо сложность на многопоточную реализацию, любо затраты на оверсинхронизацию. Приправим к этому щепотку нюбства и коллизий данных из-за гонки и получаем, что лучше жрать память и работать нормально, чем её экономить и из-за собственной криворукости страдать от трудных багов, а получить в итоге код, который работает даже медленнее, чем если бы мы не парились про оптимизацию вовсе.
Скорее так
Java : Мне больше не нужен этот кусок памяти, нужно отдать его тому кому нужнее, но отдам я ее конечно же в самый важный момент, что бы все зависло нахуй
С++: ха ха я вижу у эти программисты дальоебы, спизжу как я у них память, они даже ничего не заметят
Java : Мне больше не нужен этот кусок памяти, нужно отдать его тому кому нужнее, но отдам я ее конечно же в самый важный момент, что бы все зависло нахуй
С++: ха ха я вижу у эти программисты дальоебы, спизжу как я у них память, они даже ничего не заметят
Тем временем Assembler: Куча, GC, malloc...Пижоны - mov eax, [ebx]
В ассемблере тоже надо выделять память из кучи. На одном стеке не уедешь.
Чтобы написать коммент, необходимо залогиниться
