Вопрос: Возможно-ли объявить массив с неинициализированными полями?
Идея: есть массив с заранее установленной размерностью FMatrix: array [1..$fffffff] of Pointer. Он при старте сжирает около Гига памяти. Адреса в массиве ссылаются либо на данные, либо в "никуда". Во время работы программы поля постоянно получают новые адреса к данным, либо теряют полностью. Может у некоторых полей и вовсе никогда не появиться адреса. Может и вовсе массив остаться без адресов. Могут и все поля получить адреса в какой-то момент. Хотелось бы не занимать ОЗУ адресом $0000, если он вовсе не нужен, но индекс должен остаться закрепленным за этим полем, так как через время (секунду, день, год) может получить адрес. Как очистить память от адреса, но сохранить индекс?
Элементы массива с отсутствующими данными
Модератор: Модераторы
VirtUX
fffffff * 4 как раз и будет равняться гигу памяти. Выход - отказаться от статического массива. Или я не понял вопроса?
fffffff * 4 как раз и будет равняться гигу памяти. Выход - отказаться от статического массива. Или я не понял вопроса?
Vadim писал(а):VirtUX
Выход - отказаться от статического массива.
Нельзя мне отказываться от статического массива, т.к. на удаление, вставку и т.д. элементов очень много уходит времени. Представьте сколько будет происходить удаление FMatrix[0], а потом вставка FMatrix[5] в массиве с $fffffff размерностью. Потом привязка из вне идет именно к индексу элемента в массиве. Пример: FMatrix[5] := Addr(AnyData); Этот 5-ый элемент теперь знает о каких-то данных. Внешний элемент знает, что поместил их именно в 5-ый, оттуда он потом и будет их извлекать или там их стирать. И тут мы удалим 4-тый. Всё - данные утеряны, все начиная с FMatrix[4].
-
Sergei I. Gorelkin
- энтузиаст
- Сообщения: 1409
- Зарегистрирован: 24.07.2005 14:40:41
- Откуда: Зеленоград
Средствами языка этого по-любому не сделаеть, так что придется искать альтернативу.
1) 256M адресов - это очень много. Если предположить, что массив заполнен целиком и все адреса уникальны (каждый указывает куда-то вне массива), то вместе просто не влезет в адресное пространство 32-бит и в требованиях придется писать "x64".
2) Можно замапить всю радость в файл (memory-mapped file). Будет файл на гиг, но памяти как таковой потратится немного. Как Windows, так и Linux умеют работать по такому сценарию и хорошо кэшируют.
3) Можно завести двухуровневый массив: первый уровень - это массив из 65536 указателей на страницы по 4096 байт, второй уровень - собственно страницы. Страницы выделяются и освобождаются по мере необходимости.
4) Наконец, можно нагуглить еще какой-нибудь велосипед по фразе "sparse array" или "sparse list".
1) 256M адресов - это очень много. Если предположить, что массив заполнен целиком и все адреса уникальны (каждый указывает куда-то вне массива), то вместе просто не влезет в адресное пространство 32-бит и в требованиях придется писать "x64".
2) Можно замапить всю радость в файл (memory-mapped file). Будет файл на гиг, но памяти как таковой потратится немного. Как Windows, так и Linux умеют работать по такому сценарию и хорошо кэшируют.
3) Можно завести двухуровневый массив: первый уровень - это массив из 65536 указателей на страницы по 4096 байт, второй уровень - собственно страницы. Страницы выделяются и освобождаются по мере необходимости.
4) Наконец, можно нагуглить еще какой-нибудь велосипед по фразе "sparse array" или "sparse list".
Sergei I. Gorelkin писал(а):3) Можно завести двухуровневый массив: первый уровень - это массив из 65536 указателей на страницы по 4096 байт, второй уровень - собственно страницы. Страницы выделяются и освобождаются по мере необходимости.
Скорее всего удобно будет именно этот вариант. Остается только урегулировать двойной индекс.
Что-то типа этого в голове роется. Думаю SATA2 выручит в быстрой перезагрузке блоков. Да и можно кешировать запросы на установку нового адреса до первого запроса на его модификацию, или чтот в этом роде. Спасибо за совет - будем думать.