как сделать из слона муху

ФЛЕНОВ МИХАИЛ AKA HORRIFIC

Спецвыпуск: Хакер, номер #071, стр. 071-048-1

(WWW.VR-ONLINE.RU)

ОБРАБОТКА БОЛЬШИХ ОБЪЕМОВ ДАННЫХ В НЕБОЛЬШОМ АДРЕСНОМ ПРОСТРАНСТВЕ

СОВРЕМЕННЫЙ КОМПЬЮТЕР ОБЛАДАЕТ КАК МИНИМУМ 512 МЕТРАМИ ПАМЯТИ (ПЛЮС ФАЙЛ ПОДКАЧКИ), ПОЭТОМУ ПРОГРАММИСТЫ НЕ ОСОБО ЗАБОТЯТСЯ ОБ ЭКОНОМИИ ОПЕРАТИВКИ. МЫ ВЫДЕЛЯЕМ ПОД СОБСТВЕННЫЕ НУЖДЫ ТОННЫ ЯЧЕЕК И СТРАНИЦ, НЕ ОБРАЩАЯ ВНИМАНИЯ НА ВОЗМОЖНЫЕ ПРОБЛЕМЫ. А ВЕДЬ ПАМЯТЬ — НЕ РЕЗИНОВАЯ И МОЖЕТ КОГДА-НИБУДЬ ЗАКОНЧИТЬСЯ. ЕСЛИ КАЖДЫЙ БУДЕТ ТАК БЕЗДАРНО РАСХОДОВАТЬ СОДЕРЖИМОЕ МИКРОСХЕМ, ТО ДЛЯ НОРМАЛЬНОЙ РАБОТЫ НЕ ХВАТИТ И ГИГА ОПЕРАТИВКИ

[стоит ли экономить.]

Даже при наличии 512 мегабайт расходовать память, не думая о последствиях, глупо. Дело в том, что Windows XP в домашней редакции уже съедает от этого объема 128 метров, а профессиональная редакция отнимает и все 256. Всякие примочки и побрякушки в районе часов, антивирусы и сетевые экраны могут отнять еще 64 метра. Получается, что для других приложений остается не так уж и много места. Если одновременно будет запущен Delphi 2006, 3DS Max и Photoshop, то работа станет невыносимой, ведь эти монстры сжирают оперативку хуже вирусов.

В такие моменты вспоминаются времена MS-DOS с его ограничениями и советские машины начала 90-х, когда приходилось экономить каждый байт памяти. Сейчас байты и тем более биты уже никто не считает, а вот кило и мега считать необходимо в любой программе. И эта статья может пригодиться даже тем, кто не собирается писать программы в тяжелых условиях с ограниченным объемом памяти. Расходовать предоставленные ресурсы разумно необходимо всегда!

[массивы.]

Самый банальный и бессмысленный расход памяти происходит из-за использования массивов фиксированной длины. Допустим, что тебе нужно хранить в памяти заранее неизвестное количество чисел. Как поступить в этом случае? Можно зарезервировать максимально возможный буфер и никаких проблем. Да, проблем никаких, а вот утечка памяти произойдет достаточно серьезная.

Допустим, что ты выделил массив из 1024 чисел. Если каждое твое число типа Integer, то из-под ног утекает 4096 байт памяти. А если тип данных Int64? А если это не число, а структура размером в 100 байт? Это уже сто килобайт памяти. Десять таких массивов и драгоценный мегабайт уходит в небытие. Простейший вариант решения проблемы – в массиве хранить не сами структуры, а указатели. В этом случае размер массива значительно сокращается, но он все равно не оптимален. Мы резервируем 1024 элемента, а реально в программе может использоваться только один.

Идеальное решение – использование динамических массивов. Не стоит бояться динамики, она безобидна по сравнению с Фредди Крюгером :). Можно выделить два основных типа динамических массивов:

1 ПРОСТО ВЫДЕЛЯЕМ ПАМЯТЬ ДЛЯ ХРАНЕНИЯ ЭЛЕМЕНТОВ МАССИВА, А ПО МЕРЕ НЕОБХОДИМОСТИ ПАМЯТЬ РАСШИРЯЕТСЯ. ДАННЫЙ ВАРИАНТ САМЫЙ ПРОСТОЙ И САМЫЙ КОМПАКТНЫЙ, НО ОЧЕНЬ НЕУДОБНЫЙ, КОГДА НЕОБХОДИМО ИЗМЕНЯТЬ ПОСЛЕДОВАТЕЛЬНОСТЬ ЭЛЕМЕНТОВ (НАПРИМЕР, ДЛЯ СОРТИРОВКИ) ИЛИ УДАЛЯТЬ ЭЛЕМЕНТЫ ИЗ СЕРЕДИНЫ МАССИВА.

2 МОЖНО НАПИСАТЬ КЛАСС, КОТОРЫЙ БУДЕТ УПРАВЛЯТЬ ДИНАМИЧЕСКИМ МАССИВОМ. ПРОСТЕЙШИЙ ВАРИАНТ ТАКОГО КЛАССА НАБРОСАН В ЛИСТИНГЕ 1. ДАННЫЙ КОД УПРОЩЕН ДО МИНИМУМА. НА КОМПАКТ-ДИСКЕ ТЫ НАЙДЕШЬ БОЛЕЕ ПОЛНЫЙ ВАРИАНТ С ПРИМЕРОМ ИСПОЛЬЗОВАНИЯ. ДА, ТАКОЕ ХРАНЕНИЕ ДАННЫХ ТРЕБУЕТ НЕКОТОРОЙ ИЗБЫТОЧНОСТИ ДЛЯ КАЖДОГО ЭЛЕМЕНТА, НО ЗАТО МАССИВ ПОЛНОСТЬЮ ДИНАМИЧЕН И ЗАНИМАЕТ В ПАМЯТИ РОВНО СТОЛЬКО, СКОЛЬКО НЕОБХОДИМО. НИЧЕГО ЛИШНЕГО РЕЗЕРВИРОВАТЬ НЕ НУЖНО. А ГЛАВНОЕ — РАЗМЕРНОСТЬ МАССИВА ОГРАНИЧЕНА РАЗМЕРОМ ТИПА ДАННЫХ, КОТОРЫЙ ИСПОЛЬЗУЕТСЯ ДЛЯ ХРАНЕНИЯ КОЛИЧЕСТВА ЭЛЕМЕНТОВ.