leo CompareStringA, lstrcmpi и др. подобные вещи - не самый быстрый вариант, поэтому я не предполагал их использовать. А в самопальной процедуре проверки можно оговорить любое окончание строки
cresta Ok. Слушай, если не секрет, что за задачка такая - сортировать файлы по 1/4 миллиона и более строк. Откуда такие файлы берутся и что с ними потом делать ? (От q_q ответа я не добился, может ты пояснишь в двух словах)
leo От q_q ответа я не добился Например, log-файлы, файлы сбора информации с каких либо датчиков. При таких размерах разумнее использовать СУБД с индексными файлами В теории да, но на практике это не всегда возможно, да и сортировка нужна не постоянная, а разовая для выполнения после нее какой-либо работы.
cresta По поводу длины строк. К твоему случаю это не относится, т.к. ты, как я понял, сортируешь строки по особому критерию. А в общем случае при обычной сортировке, знание длины может дать заметный выигрыш, если в файле достаточно много длинных, совпадающих или различающихся в последних символах строк. В этом случае вместо посимвольного сравнения можно сравнивать dword-ы до первого несовпадения, после чего переходить к посимвольному.
leo Один товарищ высказал мнение, что платформа .NET жутко быстрая. И договорился до того, что быстрее, чем asm. Самый простенький пример цикла до 20 млрд .NET-программа потратила в 1.6 раза больше времени, при том что компилятор.NET зачем-то сократил количество проходов цикла: за один проход инкрементировал и старший и младший дворд счётчика. (может оттого что цикл пустой). Этот результат вызвал у товарища некоторые эмоции, и в запале он предположил ещё более странную вещь: если цикл не пустой, а скажем сортировать что-либо, то вот тут .NET и "развернётся всей своей мощью". И предложил сортировать 300000 строк. Согласен, что задача надуманная, и бесперспективная, но просто стало интересно, во сколько раз будет разница во времени. Это хорошо, если известна заранее степень однотипности данных. Если неизвестна - будет в общем случае медленнее.