Оптимизация для сбора мусора больших коллекций - PullRequest
1 голос
/ 09 марта 2011

Я читаю из базы данных большие коллекции этого типа List<Rows<Long,String,ByteBuffer>>

Затем я читаю данные из этого списка строк одну за другой и помещаю данные из них в объекты-контейнеры. Должен ли я отменять ссылки на отдельные строки в списке до нуля, когда я продолжаю читать каждую из них ИЛИ Должен ли я наконец окончательно отказаться от ссылки на них , чтобы они мусор собрали?

Так как каждая строка довольно большая и состоит из больших строк / больших двоичных объектов / текстового содержимого и т. Д. Я пытаюсь оптимизировать сборку мусора. Надеюсь это не называется преждевременной оптимизацией!?

Ответы [ 4 ]

3 голосов
/ 09 марта 2011

я бы предложил разыменовать их. это не преждевременная оптимизация, потому что, в отличие от времени, объем памяти, доступный вашей программе для ее выполнения, не настолько под вашим контролем.

3 голосов
/ 09 марта 2011

Если вы не измерили производительность вашей программы, то это преждевременная оптимизация.

(Не каждая оптимизация, выполненная до измерения, является преждевременной, но такого рода микрооптимизации есть.)

2 голосов
/ 09 марта 2011

Как сказал Ларсман, это и есть определение преждевременной оптимизации. Однако такие вопросы часто всплывают, и вместо того, чтобы забывать о них, я хотел бы сразу добавить точки профилирования (обернутые переключателем вкл / выкл - как Logger.isEnabled ()), а затем двигаться дальше. Посмотрите на http://netbeans.org/features/java/profiler.html для простого инструмента профилирования / настройки

1 голос
/ 09 марта 2011

Как уже упоминал larsmans, есть недостаток сложности.

Но может быть и недостаток производительности - обнуление ссылки подразумевает запись в память, а в современной среде сбора мусора - запись в памятьэто не обязательно просто магазин.Может также быть некоторая бухгалтерия для коллекционера - посмотрите «барьер записи» и «маркировка карты» в контексте сбора мусора.Запись также влияет на кэши процессора;в многопроцессорной системе это вызовет трафик когерентности кэша между процессорами, который потребляет пропускную способность.

Теперь я не думаю, что какой-либо из этих эффектов огромен.Но вы должны знать, что запись в память не всегда такая дешевая, как вы думаете.Вот почему вы должны профилировать перед оптимизацией, а затем снова профилировать!

...