Мемофобия

CumingSoon

Местный стендапер
1,634
12
270
Решил я написать что-нибудь на JVM, но у меня возникает странного рода паранойя. Как только смотрю на свой код, то вижу, сколько же памяти можно очистить. И тут вспоминаю, что в Java нельзя этого делать, ведь там автоматический сбор памяти. Как представлю, что программа виснет из-за фрагментации памяти, так сразу отпадает желание что-то писать на Java. Смотрю на каждый int, float, объект и понимаю: "чёрт, а тут его можно было б удалить...". Как лечиться? Переходить на С++ не особо хочу, поскольку Java мне по душе. Да и вообще, хорошо ли это? Или всё-таки стоит минимизировать затраты по памяти, удалив ненужные объекты. В общем, жду ваших предложений
*suick*
 
Никогда не наблюдал зависания проги на java из-за памяти. Просто выдели ей побольше и не парься
 
>Переходить на С++ не особо хочу

Откуда тогда такое байтоёбство?
 
Minebot написал(а):
Никогда не наблюдал зависания проги на java из-за памяти. Просто выдели ей побольше и не парься

На самом деле выделять надо меньше. Я знаю о чем говорю :p


Каждая сборка мусора - это пауза. Если выделить программе намного больше, чем ей надо (через -Xms, иначе она сама пытается взять сколько надо вплоть до -Xmx), то собираться мусор будет реже, но на каждой сборке нужно будет собирать больше. Из-за этого при слишком большом количестве выделенной памяти фризы могут быть вполне заметны.

А ещё это всё равно не поможет, потому что могу гарантировать, что как минимум на сервере у вас течет память. На клиенте скорее всего тоже, но менее критично.
 
Rumia написал(а):
>Переходить на С++ не особо хочу

Откуда тогда такое байтоёбство?

Да я не имею ничего против крестов, но это не особо мой язык. Пока что, больше всего мне понравилась Скала, хотя она ну вообще почти не годится никуда, имхо. Очень много способов сделать событие Х, отчего возникают постоянные когнитивные диссонансы - желание кодить пропадает. Пока что сижу на Kotlin.

@GloomyFolken. Так я вот и хочу уменьшить именно кол-во сборок мусора. Зачем мне забивать память, если я знаю, какой объект и когда должен быть удалён?

Алсо, пишу не под майн
 
Дак занули ссылку на объект. obj = null. gc очистит память, если на нее больше никто не ссылается.
 
Объект всё равно останется. Идея, в принципе, неплохая. Но не с Kotlin, который null-safe.
 
CoomingSoon написал(а):
Смотрю на каждый int, float, объект и понимаю: "чёрт, а тут его можно было б удалить...".

А ещё можно мутировать объекты без создания новых. Привет операция сложения векторов порождающая как минимум два объекта в памяти.

CoomingSoon написал(а):
@GloomyFolken. Так я вот и хочу уменьшить именно кол-во сборок мусора. Зачем мне забивать память, если я знаю, какой объект и когда должен быть удалён?
Можно использовать пулы объектов, выходит что-то уровня стека - забрал, использовал, положил обратно.
Автор JBullet этим принципом прекрасно воспользовался, портируя движок - написал собственную маленькую либу, которая умеет генерировать однообразный байткод за тебя.
 
Кажется ТС сидит на 8008 и ему нужно контролировать память
Знаешь сколько весит тетрис на андроид? 225 МБ!!!
А на старых тетрисах(кто помнит, такие прямоугольные были с черно-белым тхт-экраном) он весил несколько сотен байт. Вот и судите. (это немного неудачный(не в тему) пример, но аналогичный)
 
Oldestkon написал(а):
А ещё можно мутировать объекты без создания новых. Привет операция сложения векторов порождающая как минимум два объекта в памяти.

CoomingSoon написал(а):
@GloomyFolken. Так я вот и хочу уменьшить именно кол-во сборок мусора. Зачем мне забивать память, если я знаю, какой объект и когда должен быть удалён?
Можно использовать пулы объектов, выходит что-то уровня стека - забрал, использовал, положил обратно.
Автор JBullet этим принципом прекрасно воспользовался, портируя движок - написал собственную маленькую либу, которая умеет генерировать однообразный байткод за тебя.

Про мутабельность знаю, но не всегда ей место, имхо. Для меня, почему-то, векторы и матрицы вровень int'ам - при сложении и етс. производят новый объект.
Я тут пишу на lwjgl3, там тоже есть стек. Всё просто: пушаешь стек, заполняешь буферы, используешь буферы. Стек не нужен - в топку, буферы тоже очищаются. А почему я не могу его использовать... Хм, вполне себе решение проблемы. Там как раз было и выделение off-heap памяти. Прекрасно!
***
Спасибо всем, послушаю ещё советы.


Maxik001 написал(а):
Кажется ТС сидит на 8008 и ему нужно контролировать память
Знаешь сколько весит тетрис на андроид? 225 МБ!!!
А на старых тетрисах(кто помнит, такие прямоугольные были с черно-белым тхт-экраном)  он весил несколько сотен байт. Вот и судите. (это немного неудачный(не в тему) пример, но аналогичный)

Знаешь ли, если ты собрался загружать, допустим, игровую карту, а та весит по несколько сотен мегабайт. Я думаю, тут вполне полезно будет вручную очистить ненужная память карты (при смене на другую). Да и текстуру, бывает, весят по несколько мегабайт и даже десятков. А зачем мне 2 текстуры? 1 загружена, другая в памяти лежит? Незачем. (но тут lwjgl3 помогает очистить мусор)


Dahaka написал(а):
Значит на память еще кто-то ссылается.

Да нет, возможно, итерация GC ещё не подошла. Он же не постоянно работает


Длинопост, ололо
 
Почему-то у меня ощущение, что сборщик мусора справляется со сборкой мусора существенно лучше, чем это бы делал ты...
 
CoomingSoon написал(а):
Для меня, почему-то, векторы и матрицы вровень int'ам - при сложении и етс. производят новый объект.
Есть компромис: org.lwjgl.util.vector.Vector4f
Код:
public static Vector4f add(Vector4f left, Vector4f right, Vector4f dest) {
    if (dest == null)
        return new Vector4f(left.x + right.x, left.y + right.y, left.z + right.z, left.w + right.w);
    else {
        dest.set(left.x + right.x, left.y + right.y, left.z + right.z, left.w + right.w);
        return dest;
    }
}
 
GloomyFolken написал(а):
Почему-то у меня ощущение, что сборщик мусора справляется со сборкой мусора существенно лучше, чем это бы делал ты...

Да это не ощущение, а сущая правда. Но всё же есть места, где я бы мог сам очистить какую-то память
 
У меня такая-же параноя, но немного друго-го характера.

Такого, когда тебе кажется, что твоя прога сожрёт дохрена ресурсов компьютера. А потом убеждаешь себя, что 1000 вершин незатекстуреной 2D фигуры или массив int на 100 эллементов - сущий пустяк :D
 
Моя параноя превращатьется в правду при умножении матриц больших размеров (на джаве не пробовал) :)
PS: видемо у программистов принято говорить двумерный массив вместо матрицы :p
PS: я не уверен что он называется двумерный, но вы поняли)))
 
Heitem написал(а):
Моя параноя превращатьется в правду при умножении матриц больших размеров (на джаве не пробовал) :)
PS: видемо у программистов принято говорить двумерный массив вместо матрицы :p
PS: я не уверен что он называется двумерный, но вы поняли)))

А зачем тебе большие матрицы? Покажешь применения?
***
А вообще, создание переменных отдельно и по одному разу, использование ленивой инициализации и объектного пула дадут очень большой прирост в памяти.
 
Назад
Сверху