LINUX.ORG.RU

История изменений

Исправление aureliano15, (текущая версия) :

Имхо, для такой задачи разумнее использовать какую-нибудь шуструю СУБД. И переставлять, конечно же, не сами блоки, а только их индексы.

А потом следующая программа в цепочке будет делать свой анализ - так не пойдёт.

Конечно, любая задача (я говорю о задаче в широком смысле, а не об отдельной программе, которая может быть только частью общей задачи) имеет свою специфику. Но СУБД обычно неплохо справляются с сортировкой индексов, поиском по ним и фильтрацией. Думаю, что имеет смысл потестировать, как с такой задачей справится СУБД, и, думаю, в целом она справится лучше, чем собственный велосипед, сортирующий огромные записи вместо ключей. Разумеется, все программы должны работать с этой базой данных, а не с файлом, а значит, их все придётся переписать. В качестве временного варианта можно генерить из БД старый отсортированный файл. Но только временно, т. к. в таком случае выигрыша в общей скорости скорее всего не будет (хоть и замедления, думаю, тоже не будет). И ещё: есть разные СУБД. И перед переходом их тоже стоит сравнить применительно к конкретной задаче. Может, лучше подойдёт postgresql, а может — mysql, или вообще sqlite либо даже dbm.

Читаем read, потом сами парсим.

Но куда проще сразу использовать фортрановское форматированное чтение.

С этим никто и не спорит. Я говорил только о скорости ввода/вывода, но не об удобстве для программиста.

Исходная версия aureliano15, :

Имхо, для такой задачи разумнее использовать какую-нибудь шуструю СУБД. И переставлять, конечно же, не сами блоки, а только их индексы.

А потом следующая программа в цепочке будет делать свой анализ - так не пойдёт.

Конечно, любая задача (я говорю о задаче в широком смысле, а не об отдельной программе, которая может быть только частью общей задачи) имеет свою специфику. Но СУБД обычно неплохо справляются с сортировкой индексов, поиском по ним и фильтрацией. Думаю, что имеет смысл потестировать, как с такой задачей справится СУБД, и, думаю, в целом она справится лучше, чем собственный велосипед, сортирующий огромные записи вместо ключей. Разумеется, все программы должны работать с этой базой данных, а не с файлом, а значит, их все придётся переписать. В качестве временного варианта можно генерить из БД старый отсортированный файл. Но только временно, т. к. в таком случае выигрыша в общей скорости скорее всего не будет (хоть и замедления, думаю, тоже не будет). И ещё: есть разные СУБД. И перед переходом их тоже стоит сравнить применительно к конкретной задаче. Может, лучше подойдёт postgresql, а может — mysql, или вообще sqlite либо даже dbm.

Читаем read, потом сами парсим.
Но куда проще сразу использовать фортрановское форматированное чтение.

С этим никто и не спорит. Я говорил только о скорости ввода/вывода, но не об удобстве для программиста.