Как стать автором
Обновить

Комментарии 24

Спасибо! Познавательно.

оо! Познавательно. Спасибо. Полез знакомиться с Memory Analyzer =)
Если уж речь заходит о производительности и экономии памяти, не будет ли лучше использовать развернутый одномерный массив? Плюсы: минимальное потребление памяти, получение элемента за одно чтение из памяти.
Не знаю как в джаве (хотя если 32 бит, так как иначе-то), но в плюсах больше чем ана гигабайт-два выделить массив неполучится — фрагментация адресного пространства.

А вот 30 массивов по 100 мб (условно) — можно.
А что случится, если я выделю на С++ больше 2 Гб в 64 битном приложении?
exception из new вывалится.
Особенность Винды? Сорри — реально не имел таких проблем на Линуксе.
Можно хоть террабайт выделить — и отработает. Вот когда начнете инициализировать и реально пойдет выделение страниц тогда будет своп…
Да, можно. Хотя потребление изменится уже несущественно, а код может стать значительно менее читаемым из-за вычисления смещений. Можно ещё написать простенький класс (или найти готовый), реализующий это для массивов произвольной размерности, хотя тогда будут накладные расходы на вызовы функций. В каждом конкретном случае рецепт свой. К примеру, изменения в производительности в моём случае будут эфемерны.
Отвечу на первую часть: вычисление смещений в минимальном варианте заворачиваются в final методы, которые на-ура будут заинлайнены любым компилятором. Аналогично с классом.
Сразу же пришло в голову очевидное решение: упорядочить измерения массива по возрастанию… алгоритм от этого никак не пострадает.

Вообще говоря, может измениться locality of reference. Она лучше, когда измерения идут в том же порядке, в котором вложены циклы.
Правильное замечание. В моём случае производительность не была камнем преткновения и сколь-нибудь значимо не изменилась.
А не проще одномерный массив использовать и арифметику на индексах?
по крайней мере быстрее — точно
Если быть точным, заголовок объекта — это два машинных слова, соответственно, на 64-битной Java это будет уже не 8, а 16 байт.
Аналогично, заголовок массива — три машинных слова, на 64-битной Java — 24 байта.
Рекомендую также по теме вот эту презентацию. Один из разработчиков Twitter делится своим опытом в части модели памяти Java, сборки мусора и оптимизации.
Вот спасибо! Кратко, лаконично и полезно — в избранное.
Массивы float[14761]: 14 761*4+12 = 59 056 байт, всего 1 000 таких массивов, итого 59 056 000 байт.
Скорректируй их всего 500
1000. Два по 500.
Ошибся я, извините
Вообще-то проблема только в том что последний массив — это float[2]
Если бы там был float[100], то итоговый суммарный оверхед был бы не 350%, а доли процента.

Так что уточненная мораль сей истории состоит не в том, чтобы упорядочивать вложенные массивы по возрастанию, а в том, чтобы не создавать очень много очень мелких обьектов, когда есть возможность вместо этого создать обьектов не много, но крупных.
Ну не доли процента, а минимум (416/400-1)*100% = 4%.
Согласен, большая часть уходит на выравнивание мелких объектов
У вас еще перформанс должен поменяться если у вас там матиматика с обходом массива…

Вообще самый первый индекс должен быть максимальным — наилучшее использование кэша. Первый — тот который по строке бежит я имею ввиду.
а если его представить как одномерный?
вычисления от этого не пострадают?
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории