Сортировка большого файла с ограничениями памяти - внешняя сортировка

1

Я много читаю об этой идее, и я читал много разных людей, задающих вопросы об этом. Я наткнулся на это: http://javatroops.blogspot.ca/2012/12/sort-very-large-text-file-on-limited.html, и у меня были некоторые вопросы. (Извините, я не уверен в точном правиле связывания блогов, а что нет).

Я понимаю основы внешней сортировки, когда я разбиваю файл на временные файлы, а затем выполняю сортировку слияния по количеству временных файлов. Однако этот метод будет подчеркивать, что ввод-вывод не будет из-за всех файлов? Я мог бы ограничить количество открываемых файлов за один раз, выполнив несколько проходов n-way merge, но я хотел найти улучшения.

Поэтому, читая это сообщение в блоге выше, я понимаю идею решения 2, но это решение 3, но я не понимаю его реализации на Java. В середине обоих решений после того, как файл был разделен на временные файлы, все файлы считываются в BufferedReaders (мини-вопрос о буферизаторах и fileraders): просто он добавляет буферизацию и ускоряет ввод-вывод, но не меняет удобство использования с точки зрения программиста?), а затем сопоставлено. Не влияет ли этот процесс сопоставления на память? Я смущен тем, как вставка в TreeSet будет занимать память, но вставки в TreeMap не будут. Как работает решение 3?

  • 0
    Это не «подчеркнет ввод-вывод из-за количества файлов». Количество открытых файлов не имеет к этому никакого отношения. Слияние, безусловно, требует интенсивного ввода-вывода, потому что вы вряд ли делаете что-либо еще, кроме ввода-вывода, но это правда, независимо от того, объединяете ли вы два файла или 100. Это не становится «более верным» с увеличением N. Использование буферизованного I / O смягчает его в небольшой степени и в значительной степени уменьшает количество системных вызовов.
  • 0
    Решение 2 в цитате - очень плохая попытка. Кажется, он не слышал о замене-выборе или многофазном слиянии. Это можно сделать гораздо эффективнее, чем это. Подразумеваемое Решение 3 с отображенными в память файлами совершенно непрактично, как я обнаружил несколько десятилетий назад,
Показать ещё 3 комментария
Теги:
sorting
io
memory-management
map

1 ответ

0
Лучший ответ

Однако этот метод будет подчеркивать, что ввод-вывод не будет из-за всех файлов? Я мог бы ограничить количество открываемых файлов за один раз, выполнив несколько проходов n-way merge, но я хотел найти улучшения.

Использование памяти всегда будет быстрее, по крайней мере, на 10 - 1000 раз быстрее. Вот почему мы используем память и стараемся, чтобы у нас было столько, сколько нам нужно. Если вы собираетесь использовать IO сильно, вы должны быть осторожны, как вы получаете доступ к данным, поскольку чем больше вы используете IO, тем медленнее вы будете.

просто он добавляет буферизацию и ускоряет ввод-вывод, но не меняет удобство использования с точки зрения программиста?)

Основное преимущество заключается в том, что он поддерживает линии чтения. (И это делает буферизацию)

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

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

Как работает решение 3?

Я предлагаю вам спросить автора, что он имел в виду.

Поделиться

Ещё вопросы

Сообщество Overcoder
Наверх
Меню