Главная страница
Top.Mail.Ru    Яндекс.Метрика
Текущий архив: 2006.01.08;
Скачать: CL | DM;

Вниз

Динамическое сжатие данных в памяти   Найти похожие ветки 

 
AlexanderS   (2005-12-07 06:17) [0]

Есть такой вопрос - можно ли сжать в памяти некоторый массив данных (только для чтения), может какой-то компонент существует, либо загрузить в память уже сжатый и динамически распаковывать по мере необходимости. Имеется файл 400 с лишним мегов, который zip-ом на минимуме сжатия получается 70, очень бы хотелось разместить данные в оперативной памяти для быстрого доступа.


 
Васяня   (2005-12-07 06:20) [1]

И что ты пологаешь что постоянное сжатие и распаковка информации будет осуществляться быстрее нежели чтение несжатой информации с винта?


 
AlexanderS   (2005-12-07 06:28) [2]

постоянной будет только распаковка, и думаю что да
во всяком случае что ты думаешь чувствует хард когда ему десятками-сотнями тысяч в секунду идут запросы на чтение по одному байту в разные части 400-мегового файла :)


 
TUser ©   (2005-12-07 06:33) [3]

Не надо размещать в памяти ни 400, ни 70 метров. Я бы использовал либо TFileStream, либо WinAPI функции управляющие отображением файлов в память. И в том, и в другом случае, в памяти постоянно будет находиться только та часть файла, с которой ты работаешь.


 
Brother ©   (2005-12-07 06:35) [4]

Согласен с [3]


 
Васяня   (2005-12-07 06:36) [5]


> постоянной будет только распаковка

гыыыы... шутник :) если при каждом твоем запросе 1 байта в секунду ты будешь распаковывать каждый раз этот кусок, как ты думаешь что быдет при это испытавать процессор? не попросит ли он тебя убить себя за не грамотно написанный код?

З.Ы. Какая задача вообще? изначально...?


 
AlexanderS   (2005-12-07 09:31) [6]

[3] и согласный с ним - повторяю - запросы частые и случайтые, так что либо мы выделяем под кеш значительную часть памяти, либо TFileStream отдыхает, ибо в любом случае операционка выделяет максимум свободной оперативки под кэш диска

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

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


 
Alexander Panov ©   (2005-12-07 09:46) [7]

ftp://ftp.almar.net.ru/pub/packer/packer.rar

Пример работы с BZIP.


 
app ©   (2005-12-07 11:33) [8]

AlexanderS   (07.12.05 09:31) [6]
Ты не противорешь? Сначала пишешь про либо загрузить в память уже сжатый , а потом ведешь уже речь про куски, кстати при кусках вряд ли будет размер 70 мб.
Компоненты не видал, а вот драйвера "удвоители" оперативной памяти слышал.
Ты лучше посмотри в сторону Memory Mapped Files - это как раз то, о чем ты мечтаешь.


 
jack128 ©   (2005-12-07 11:46) [9]

по крайней мере с семеркой ZLib поставляется..


 
TUser ©   (2005-12-07 11:46) [10]


> [3] и согласный с ним - повторяю - запросы частые и случайтые

Значит плохой алгоритм, имхо. Опиши нам, что ты все-таки, собираешься делать?



Страницы: 1 вся ветка

Текущий архив: 2006.01.08;
Скачать: CL | DM;

Наверх




Память: 0.49 MB
Время: 0.014 c
8-1123180880
Ландграф Павел
2005-08-04 22:41
2006.01.08
возможно ли понизить битрейд mp3 без схемы mp3>wav>mp3


14-1134585040
Igorek
2005-12-14 21:30
2006.01.08
Ретрансляция интернет радиостанций по локалке


2-1134918079
Out84
2005-12-18 18:01
2006.01.08
Работа с ini файлами


14-1133544385
Uncle Archi
2005-12-02 20:26
2006.01.08
Matrix: The Path Of Neo


3-1131619501
Дмитрий_Б
2005-11-10 13:45
2006.01.08
MultiSelect в Гриде