1 млн. маленьких файлов VS 1 большой файл

Всем привет!
В одном моем проекте используется вывод на экран карты СПб, скаченной из Гугла.
Карта состоит из тайлов 256х256 пикселей.
Вопрос состоит в том, как лучше всего хранить все эти тайлы?
Раскиданными по папкам или загрузить их всех в один большой файл из которого лишь считывать отдельные массивы данных, по мере необходимости?

С одной стороны, нужно обеспечить быструю переносимость программы с одного ПК на другой ПК, желательно без использования архиваторов и прочего.
С другой стороны, нужно обеспечить высокое быстродействие развернутой на ПК программы.
Потому что самое узкое место в программе именно загрузка необходимых тайлов в память.

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

Цитата Вуйко з полонини @ 12.08.11, 08:18

в программах обычно куски карт порезаны на мелкие части, и разбросаны по папкам.

Это то я знаю.

Цитата Вуйко з полонини @ 12.08.11, 08:18

А для быстрой переносимости можно и инсталлер написать.

Речь не только об установке, но и переносе уже работающей программы со всем содержимым на другой ПК.

Цитата Polinom2686 @ 12.08.11, 08:24

Это то я знаю.

Я так думаю, что это не с проста так сделали

Цитата Polinom2686 @ 12.08.11, 08:24

Речь не только об установке, но и переносе уже работающей программы со всем содержимым на другой ПК.

Тоесть ты хочешь перенести и какие-то данные юзера? Так можно сделать синхронизацию и залить данные юзера куда-то на сервак, а потом слить обратно, тоесть перенос идёт так:
1) Инсталяция софтины
2) Юзер логинится и тянет автоматом данные с сервака.
...
PROFIT!

Цитата Вуйко з полонини @ 12.08.11, 08:49

Тоесть ты хочешь перенести и какие-то данные юзера?

Не только. Желательно выполнить полный перенос программы.

Цитата Вуйко з полонини @ 12.08.11, 08:49

Я так думаю, что это не с проста так сделали

Откуда мы знаем, чем руководствовались разработчики.
Вон Blizzard все данные в MPQ хранят.

Сообщение отредактировано: Polinom2686 - 12.08.11, 08:56

Цитата Polinom2686 @ 12.08.11, 08:56

Не только. Желательно выполнить полный перенос программы.

Так полный перенос = перенос софтины + перенос данных юзера. Или я не прав? Первая часть переинсталится, а вторая - легко синхронизируема.

Цитата Polinom2686 @ 12.08.11, 08:56

Откуда мы знаем, чем руководствовались разработчики.
Вон Blizzard все данные в MPQ хранят.

А ты не смотри на геймы, ты смотри на оффлайновые карты (Maverick). Если сделать мелкие кусочки, то, к примеру, можно легко спортировать на мобильную платформу. В гугле ж тоже не простые ребята сидят.

Цитата Polinom2686 @ 12.08.11, 08:56

Откуда мы знаем, чем руководствовались разработчики.

Я думаю, что железо в этом плане - критично.

Цитата Вуйко з полонини @ 12.08.11, 09:06

Так полный перенос = перенос софтины + перенос данных юзера. Или я не прав? Первая часть переинсталится, а вторая - легко синхронизируема.

Ну, логично. Обдумаю.

Цитата Вуйко з полонини @ 12.08.11, 09:06

А ты не смотри на геймы, ты смотри на оффлайновые карты (Maverick). Если сделать мелкие кусочки, то, к примеру, можно легко спортировать на мобильную платформу. В гугле ж тоже не простые ребята сидят.

ОК,посмотрю на Maverick.

Так, почитал я про цифровую картографию.
Везде используется хранение картинок в виде файлов раскиданных по папкам.
Пока на этом и остановлюсь.

Но все таки вопрос открыт. Что быстрее: считывать отдельные файлы или считать блок данных из одного большого файла?

простой файл - это неиндексированный массив данных
понятия не имею какие у тебя файлы - так что думай сам как тебе удобней.
у меня, например, съём данных сеанса (порядок - десятки гигабайт) организован следующим макаром:
данные - бешеный поток кадров, кадр - 64кб. в оперативке небольшой буфер, отдельный поток при достижении в буфере больше ста кадров фигачит их на диск в файл, освобождает память. файл собирает порядка несколько тыщ кадров, потом следующий файл. по окончании сеанса файлы дружно переливаются в БД для дальнейшей работы.
собсено моя практика показывает, как мне кажется, элементарные вещи - с оперативкой работать быстро, но её мало; с файлами работать медленнее, но памяти больше; с БД работать еще медленнее, но записи уже индексированы - поиск отдельного блока происходит быстро.

принципиальной разницы в размере файлов нету, если, конечно, "маленькие" это не 1мб, а "большие" это не 2гб

Сообщение отредактировано: _lcf_ - 13.08.11, 13:14

Цитата _lcf_ @ 13.08.11, 13:10

принципиальной разницы в размере файлов нету, если, конечно, "маленькие" это не 1мб, а "большие" это не 2гб

Маленькие: 3-6 кб
Большие: 500-600 МБ

Цитата Polinom2686 @ 13.08.11, 16:51

Маленькие: 3-6 кб

Это не маленькие - это очень маленькие.

Если файлы хранятся на диске - их удобнее собрать в один индексированный файл. Перемещение указателя чтения в файле производится быстро. В результате для считывания нужной порции понадобится два поиска/чтения.
Если данные имеют фиксированную длину - можно обойтись без индекса, вычисляя положение нужного фрагмента.
Удобно, если номер фрагмента можно определить сразу, а не искать по имени.

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

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

Ура!
amk, держи плюс.

Согласен с amk, для чтения - лучше один большой файл. Особенно если "маленькие" означает копеечный размер:

Цитата Polinom2686 @ 13.08.11, 16:51

Маленькие: 3-6 кб

Причины:
1) все уже слышали, что винты отличаются от дискет тем, что хранят файлы не в секторах, а в кластерах (группах секторов). Поэтому мелкие файлы имеют высокий шанс неэффективно расходовать дисковое пространство (т.к. кластера от 4 кило и выше)
2) винда оперирует страницами памяти в 64 кило - что еще хуже (несколько неосторожных движений - и своп-фал кончился ... шутка, конечно, но смысл всё тот же: неэффективно жуётся память)
3) каждый файл - это лишние ресурсы операционки на поддержание, открытие/закрытие файла тоже не моментальное действие

Цитата amk @ 14.08.11, 09:59

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

Ну, есть такое, хотя не столь критично: скажем, большинство флэшек форматировано в FAT32 - а это означает максимум 4 гига на 1 файл, тот же DVD-образ уже не влезет без нарезки. С другой стороны, файловые операции в том же Win32 API умеют обрабатывать 64-битные смещения и размеры.

Если посмотреть на индустриальные best practises, то
1) MS SQL Server юзает подход "большой файл". Разбиение на части там тоже применяется, но преследует иные цели (например, файл лога отделен от файла данных, можно дробить базу на несколько файлов с целью ускорения доступа etc)
2) Даже старые игрушки MS-DOS часто юзали большие файлы вместо солянки из мелочи. Тот же WAD-формат для DOOM, аналогичное решение было в Descent и прочих.

Mr.Delphist, благодарю за пояснения.

Как ни странно, но на дискете единицей распределения тоже является кластер, а не блок. Просто из-за малого размера дискеты практичнее делать кластер размером 1-2 блока, а не 8, как на жестком диске.

Вообще FAT32 гарантированно работает с файлами до 2 гиг. На размерах от 2 до 4 кое-что не работает.

Файлы DOS-овских игр обычно имели размер до 20 Мб. Основной довод для такого объединения - ограничение на число одновременно открытых файлов. По умолчанию всего 20 файлов при максимуме 255. Всего 20 файлов также помещалось в таблице дескрипторов программы. Большой файл можно открыть при запуске игры и закрыть при ее завершении. Тем более и DOOM и Descent работают в защищенном режиме (с использованием DOS4GW), а для системных вызовов приходится переключаться в реальный.