ЕО
не должно ли это в практически любом случае быть медленее?
Если данные очень разряженные и слишком неслучайные, то обычный lz4 может пожать в сотни раз. Но обычно, конечно, сжатие это про ускорение чтения, а не записи
Size: a a a
2020 February 14
VS
не должно ли это в практически любом случае быть медленее?
ну смотри, lz4 жмет 700+ МБайт в секунду на ядро, если у тебя диск медленее чем эта цифра а файл жмется хотя бы процентов на 5, уже выгодно выходит
VS
особенно если файл тебе нужен или весь или никак
RS
ну смотри, lz4 жмет 700+ МБайт в секунду на ядро, если у тебя диск медленее чем эта цифра а файл жмется хотя бы процентов на 5, уже выгодно выходит
тоже верно, в общем этот момент можно сделать конфигурируемым зависит от ситуации использования
VS
вопрос в том как тебе потом данные нужны
CF
так не бывает
сорри, так пакет в пакет, не на то навзание посмотрел. все получилось, спасибо
ЕО
вопрос в том как тебе потом данные нужны
Так можно же поточно жать и случайный доступ тоже будет
DP
а как адресоваться-то? 🙂
ЕО
По заранее построенному индексу
DP
ага
VS
Так можно же поточно жать и случайный доступ тоже будет
ага, просто индекс нужно делать
VS
а листинг от большого числа файлов не просядет?
в какой-то момент просядет, поэтому народ иногда еще и директорий много делает )
VS
типа 1000 директорий по 1000 файлов в каждой
DP
в какой-то момент просядет, поэтому народ иногда еще и директорий много делает )
на ssd он сильно не сразу просядет
VS
или фоновые процессы которые мусор собирают (в смысле склеивают файлы в более жирные)
VS
на ssd он сильно не сразу просядет
там надо чуть аккуратнее быть, ибо тот же filepath.Walk сортирует файыл в директории по имени и на 1+М это уже заметно будет
VS
но да, если порядок обхода не важен, то можно избежать просадок
DM
в какой-то момент просядет, поэтому народ иногда еще и директорий много делает )
я так, наводящие вопросы задаю
VS
я так, наводящие вопросы задаю
ну так вопрос в юз-кейсе и того что такое большое число файлов )