Применение искинов - шоссе империализма (Стенгазета русификаторов ИТ)

Информация о пользователе

Привет, Гость! Войдите или зарегистрируйтесь.


Вы здесь » Применение искинов - шоссе империализма (Стенгазета русификаторов ИТ) » управление памятью » Критерии оценки качества системы управления памятью


Критерии оценки качества системы управления памятью

Сообщений 1 страница 2 из 2

1

- общее время затрачиваемое на управление памятью (его надо снижать)
- количество грязной неиспользуемой памяти в течение прогона, ведёт к увеличению требований к памяти
- количество вспомогательной памяти, требуемой для управления (например память под счётчики количества ссылок на объект)
- время на доступ к объекту (включая промахи мимо страниц памяти и кеша процессора)
- время пауз в процессе сборки (его стараются минимизировать)
- сложность алгоритма сборки (влияет на производительность, настраиваемость, поддерживаемость, корректность и безопасность)
- эноргопотребление (для мобильных устройств)
- вытирание/износ flash-памяти (минимизация количества операций записи)

Отредактировано Лис (2017-07-27 06:35:44)

0

2

- количество грязной неиспользуемой памяти в течение прогона, ведёт к увеличению требований к памяти

Очень спорное утверждение. Память выделяется поблочно - килобайтами и мегабайтами, если у Вас свободный блок в полмегабайта, то килобайт мусора вообще никак не влияет на ситуацию. То есть тут нужны статистические показатели причем для каждой программы индивидуально. Большинство программ не настраиваются и нет возможность договориться с ОСью сколько памяти Вам нужно. То есть Вы затребуете под массив - 42 байта, а операционка даст страницу в виде 64 байт или 128 (256) в зависимости от самой ОСи. Или Вам надо под структуру 14 Кб, получите 16 Кб и повлиять на это никак нельзя. Также и с файловой системой - там тоже чтение/запись поблочно, поэтому например запись всего блока намного быстрей, чем например побайтно тот же самый блок.  Или запись блока быстрей, чем запись двух полублоков. Поэтому люди пишут файлы поблочно и мучаются только с остатком меньше блока.
Например, тест проводил такой - пустое оконное приложение на ФриПаскале с объявлением массива Integer в 1000 элементов занимает в ОЗУ 2,7 Мб (настройки по умолчанию, то есть проект в отладке со спецсимволами и дополнительной информацией). Делаю массив в 100000 элементов - результат тот же. То есть ОСь выделила память с запасом.
Продолжил эксперименты. Возникли подозрения, что меня накалывает компилятор - начал работать с массивом, для 100000 память выросла на 3,1 Мб, что в целом адекватно выделенному массиву. Тогда я уменьшил массив до 10 000 и размер программы в памяти снова 2,7 мб (при этом массив также гоняется, чтобы компилятор не выкинул объявление из программы, а реально учитывал массив). То есть эти 40 000 байт (integer же 4 байта) в системе заранее зарезервированы ОСью для нужд программы. А память выделяется только когда программа хочет больше чем ей выдается по умолчанию. Эти результаты говорят о том, что количество грязной памяти не является прямым показателем (ну я сомневаюсь, что сборщик мусора оставит 40 000 байт мусора). То есть ОСь предположительно "знает" что Вы будете играться с мусором и потому дает Вам песочницу чуть больше, чтобы не дергаться из-за каждого Вашего байта.
Эксперимент №2: Программа создает динамический массив размером 10 000 элементов Integer, забивает его нулями (чтобы компилятор не с жульничал и реально выделял память), затем высвобождает динамический массив. То есть уже не статика, а работа с кучей. Эффект тот же - 2,7 мб.
Эксперимент №3: Программа создает динамический массив размером 100 000 элементов Integer, забивает его нулями (чтобы компилятор не с жульничал и реально выделял память), затем высвобождает динамический массив. То есть уже не статика, а работа с кучей. Эффект 3.1 мб!!! То есть операционка "не пожелала" забирать 400 кб обратно (я бы тоже не чесался при 8-то гб памяти). Следовательно после этого можете хоть обмусориться, пока операционке не понадобиться, она неиспользованные блоки не заберет и они будут по-прежнему числиться за программой.

- количество вспомогательной памяти, требуемой для управления (например память под счётчики количества ссылок на объект)

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

- сложность алгоритма сборки (влияет на производительность, настраиваемость, поддерживаемость, корректность и безопасность)

Как правило более сложные алгоритмы более производительны.

Отредактировано utkin (2017-07-27 09:46:23)

0


Вы здесь » Применение искинов - шоссе империализма (Стенгазета русификаторов ИТ) » управление памятью » Критерии оценки качества системы управления памятью