Размеры массивов в Java

[@javax]

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

[@dokwork]

оо! Познавательно. Спасибо. Полез знакомиться с Memory Analyzer =)

[@cypok]

Если уж речь заходит о производительности и экономии памяти, не будет ли лучше использовать развернутый одномерный массив? Плюсы: минимальное потребление памяти, получение элемента за одно чтение из памяти.

[@f0b0s]

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

А вот 30 массивов по 100 мб (условно) — можно.

[@ShapovalovTS]

А что случится, если я выделю на С++ больше 2 Гб в 64 битном приложении?

[@BarsMonster]

exception из new вывалится.

[@DustCn]

Особенность Винды? Сорри — реально не имел таких проблем на Линуксе.
Можно хоть террабайт выделить — и отработает. Вот когда начнете инициализировать и реально пойдет выделение страниц тогда будет своп…

[@tagir_valeev]

Да, можно. Хотя потребление изменится уже несущественно, а код может стать значительно менее читаемым из-за вычисления смещений. Можно ещё написать простенький класс (или найти готовый), реализующий это для массивов произвольной размерности, хотя тогда будут накладные расходы на вызовы функций. В каждом конкретном случае рецепт свой. К примеру, изменения в производительности в моём случае будут эфемерны.

[@cypok]

Отвечу на первую часть: вычисление смещений в минимальном варианте заворачиваются в final методы, которые на-ура будут заинлайнены любым компилятором. Аналогично с классом.

[@nikitadanilov]

Сразу же пришло в голову очевидное решение: упорядочить измерения массива по возрастанию… алгоритм от этого никак не пострадает.

Вообще говоря, может измениться locality of reference. Она лучше, когда измерения идут в том же порядке, в котором вложены циклы.

[@tagir_valeev]

Правильное замечание. В моём случае производительность не была камнем преткновения и сколь-нибудь значимо не изменилась.

[@Dair_Targ]

А не проще одномерный массив использовать и арифметику на индексах?

[@Throwable]

по крайней мере быстрее — точно

[@ashofthedream]

По поводу использовании памяти в яве есть очень, очень хорошая презентация.

[@forketyfork]

Если быть точным, заголовок объекта — это два машинных слова, соответственно, на 64-битной Java это будет уже не 8, а 16 байт.
Аналогично, заголовок массива — три машинных слова, на 64-битной Java — 24 байта.
Рекомендую также по теме вот эту презентацию. Один из разработчиков Twitter делится своим опытом в части модели памяти Java, сборки мусора и оптимизации.

[@sphinks]

Вот спасибо! Кратко, лаконично и полезно — в избранное.

[@olegdunkan]

Массивы float[14761]: 14 761*4+12 = 59 056 байт, всего 1 000 таких массивов, итого 59 056 000 байт.
Скорректируй их всего 500

[@tagir_valeev]

1000. Два по 500.

[@olegdunkan]

Ошибся я, извините

[@zuborg]

Вообще-то проблема только в том что последний массив — это float[2]
Если бы там был float[100], то итоговый суммарный оверхед был бы не 350%, а доли процента.

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

[@tagir_valeev]

Ну не доли процента, а минимум (416/400-1)*100% = 4%.

[@olegdunkan]

Согласен, большая часть уходит на выравнивание мелких объектов

[@DustCn]

У вас еще перформанс должен поменяться если у вас там матиматика с обходом массива…

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

[@dimazaur]

а если его представить как одномерный?
вычисления от этого не пострадают?