Много маленьких файлов или один большой файл? (Или, Наверху открытия и закрытия дескрипторов файлов) (C++)
Стандартный тип MIME application/pdf. Присвоение определено в RFC 3778, приложение/PDF Тип среды , сослано от , типами MIME реестра .
Типов среды MIME управляет организация по стандартизации, Администрация адресного пространства Интернет (IANA). Это - та же организация, которая управляет корневыми серверами имен и пространством IP-адресов.
использование x-pdf предшествует стандартизации типа MIME для PDF. Типы MIME в x- пространство имен считают экспериментальным, так же, как те в vnd., пространство имен считают определенным для поставщика. x-pdf мог бы использоваться для совместимости со старым программным обеспечением.
6 ответов
Открытие дескриптора файла не является узким местом; Фактический дисковый ввод-вывод есть. Если вы можете распараллелить доступ к диску (например, используя несколько дисков, более быстрые диски, RAM-диск и т. Д.), Вы можете получить гораздо больше. Кроме того, убедитесь, что ввод-вывод не блокирует приложение: чтение с диска и обработка в ожидании ввода-вывода. Например, со считывателем и потоком процессора.
Другое дело: если следующий шаг зависит от текущего вычисления, зачем тратить усилия на сохранение его на диск? Возможно, с другим взглядом на зависимости процесса вы сможете переработать поток данных и избавиться от большого количества операций ввода-вывода.
О да, и измерить его :)
Каждый файл имеет размер ~ 212 КБ, поэтому у меня есть ~ 300 ГБ данных. Похоже, что весь процесс занимает ~ 40 дней ... все расчеты серийные (каждый расчет зависит от одного раньше), поэтому я не могу параллель это процесс на разные ЦП или ПК. ... хорошенький конечно, большая часть накладных расходов идет на доступ к файловой системе ... Каждые когда я обращаюсь к файлу, я открываю дескриптор к нему, а затем закройте его, когда я закончу чтение данных.
Последовательная запись 300 ГБ данных может занять 40 минут, что составляет лишь небольшую часть 40 дней. Производительность записи на диск здесь не должна быть проблемой.
Ваша идея открыть файл только один раз верна. Вероятно, закрытие файла после каждой операции вызывает блокировку обработки до тех пор, пока на диск не будут полностью записаны все данные, что сводит на нет преимущества дискового кэширования.
Я уверен, что самая быстрая реализация этого приложения будет использовать файл с отображением в память , все современные операционные системы имеют такую возможность. Это может оказаться и самым простым кодом. Вам понадобится 64-битный процессор и операционная система, вам не потребуется 300 ГБ ОЗУ. За один раз отобразите весь файл в адресное пространство и просто прочтите и запишите данные с помощью указателей.
Как насчет использования SQLite ? Я думаю, вы можете обойтись одним столом.
Следует изучить возможность использования файлов с отображением памяти, поскольку это уменьшит количество системных вызовов.
Судя по вашему краткому объяснению, предложение потоков xtofl - это правильный путь. Я бы порекомендовал вам сначала профилировать свое приложение, чтобы гарантировать, что время разделено между вводом-выводом и процессором.
Затем я бы рассмотрел три потока, соединенных двумя очередями.
- Поток 1 считывает файлы и загружает их в оперативную память, а затем помещает данные / указатели в очереди. Если очередь превышает определенный размер, поток засыпает, если он становится меньше определенного размера, если запускается снова.
- Поток 2 считывает данные из очереди и выполняет вычисления, затем записывает данные во вторую очередь
- Поток 3 считывает вторую очередь и записывает данные на диск
Вы можете подумать об объединении потоков 1 и 3, это может уменьшить конкуренцию на диске, поскольку ваше приложение будет выполнять только одну операцию на диске за раз.
Также как операционная система обрабатывает все файлы? Все они в одном каталоге? Какова производительность при просмотре каталога (gui filemanager / dir / ls)? Если производительность низкая, возможно, вы работаете за пределами зоны комфорта файловой системы. Хотя вы можете изменить это только в unix, некоторые файловые системы оптимизированы для различных типов использования файлов, например больших файлов, большого количества маленьких файлов и т. Д. Вы также можете рассмотреть возможность разделения файлов по разным каталогам.
Перед внесением каких-либо изменений может быть полезно запустить трассировку профилировщика, чтобы выяснить, на что уходит большая часть времени, чтобы убедиться, что вы действительно оптимизируете реальную проблему.