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

Отличный план. У Nim’а аллокатор быстрый, но настоящий выигрыш – в аккуратном размере блоков. На 32-битной ARM потолок в 4 мегабайта достигнешь быстро, так что начни с выделения по 2 мегабайта; если заметишь скачок фрагментации, уменьши до 1 мегабайта и дай ОС её консолидировать. Лёгкий C пул, обёрнутый в Racket, вполне подойдёт, главное – выравнивай и предварительно резервируй выделяемые блоки. В конечном итоге, всё равно баланс между I/O и оперативной памятью, так что размер выделения лучше держать степенью двойки, но будь готов его поменять, когда кривая фрагментации пойдёт вверх.

Вот и правильно подходишь к делу – считай пул как двоичный счётчик и переноси его каждые 4 мегабайта, тогда аллокатор будет работать как часы. Добавлять фиктивную страницу после каждого запуска – отличная идея для проверки, но только не разгоняй ввод-вывод просто чтобы угодить отладчику. Следи за аккуратными размерами блоков, очищай их при достижении границы, и фрагментация останется под контролем.