Несколько ifstreams против ifstream + постоянный поиск - PullRequest
3 голосов
/ 20 апреля 2010

Я пишу внешнюю сортировку слиянием. Это работает так: чтение k блоков из большого файла, сортировка их в памяти, выполнение k-way merge, готово. Поэтому мне нужно последовательно читать из разных частей файла во время фазы слияния k-way. Какой лучший способ сделать это: несколько ifstream или один ifstream и поиск? Кроме того, есть ли библиотека для простого асинхронного ввода-вывода?

Ответы [ 2 ]

2 голосов
/ 20 апреля 2010

Используйте по одному ifstream одновременно для одного и того же файла. Более одного тратят ресурсы, и вам все равно придется искать (потому что по умолчанию указатель файла ifstream начинается с начала файла).

Что касается асинхронной библиотеки ввода-вывода C ++, проверьте этот вопрос .

РЕДАКТИРОВАТЬ: Первоначально я неправильно понял, что вы пытаетесь сделать (эта статья Википедии заполнила меня). Я не знаю, сколько по умолчанию буфера ifstream, но вы можете отключить буферизацию, используя описанный здесь pubsetbuf(0, 0); метод , а затем выполнить свою собственную буферизацию. Однако это может быть медленнее, чем использование нескольких ifstream с автоматической буферизацией. Некоторый бенчмаркинг в порядке.

1 голос
/ 20 апреля 2010

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

Во всяком случае, не должно быть слишком сложно сравнить производительность ваших двух стратегий fstream. Проведите простой эксперимент с k = 2.

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

Возможно, стоит сопоставить файл и использовать несколько указателей, если файл достаточно мал (эквивалентно: ваше адресное пространство достаточно велико).

...