Как упростить данный код? Жутко тормозит при обработке больших файлов!

Хранить данные в БД. Если же требуется работа именно с .txt, то логичней читать файл построчно через Assign...Readln, нежели грузить его целиком в стринглист.

TStreamReader/TStreamWriter.

Необходима работа именно с txt файлом, если не трудно киньте кто-нибудь код!

Как-то так (без обработки ошибок):

Если у кого еще есть варианты буду признателен!

Это сообщение отредактировал(а) Данкинг - 19.4.2012, 00:09

Не обижайтесь, но во-первых это ваше решение не соответствует задаче в топике. А во-вторых задаче не соответствует ваше высказывание 
Ведь в задаче требуется некий вариант сортировки/выбора из списка неких отдельных элементов с целью создать по некоему условию несколько новых списков. Мой исторически любимый метод доступа к текстовым файлам "Assign,Readln,Writeln" совершенно очевидно будет жестоко тормозить в отличие от методов чтения файла "целиком" с последующей обработкой строк в памяти.

А автору я посоветую учесть что Application.ProcessMessage конечно вещь хорошая и полезная. Но она в чём-то похожа на одеколон/духи. И то и другое хорошо в меру, а избыток и того и другого обычно портит жизнь всем.
И уж тем более задуматься на вопросом - зачем вызывать  на каждой итерации цикла? При том что файлы большие а ширина экрана в пикселях маленькая (даже ну очень маленькая по сравнению с количеством строк в "больших" текстовых файлах). А ведь вызов progressbar1.StepBy(1) в сочетании с Application.ProcessMessage вызывает принудительную перерисовку на каждой итерации цикла! Вот и тормоза.

Это сообщение отредактировал(а) northener - 19.4.2012, 00:39

Почему это, не понял?

Тоже не понял. Т.е. построчное чтение будет тормозить? С какой стати? Я сам для подобного использую Assign...Read и ничего не тормозит, а уж тем более по сравнению, как если бы я в стринглист грузил.

Для подобных задач нужно использовать data-driven подход. Достаточно префиксы телефонов сопоставить с номерами групп. Можно даже хранить эти ассоциации в файле, чтобы для добавления нового префикса или группы не было необходимости перекомпилировать код. Текущий подход с простынями однотипных проверок — частый гость на удивительном коде.
По поводу радостей вида AssignFile/CloseFile. Хватит. Остановитесь. Это из процедурного мира. Ну серьезно, сколько еще десятилетий должно пройти, чтобы этот подход вымер. Есть гораздо более удобные сущности TStreamReader/TStreamWriter и прочие.
Далее про Application.ProcessMessage. В большинстве случаев это очень грязный хак. И это именно тот случай. Ознакомьтесь с потоками — это путь развития правильного программиста.
И последнее. Если можно полностью не загружать файл в память, то нужно его не загружать. Вариант с TStringList несколько быстрее, но при достаточно большом размере исходного файла памяти просто не хватит.

Это сообщение отредактировал(а) Qu1nt - 19.4.2012, 10:44

А зачем вымирать простым, наглядным и понятным операторам?  

Кому как.

Вот тут уже я не соглашусь с таким категоричным суждением. Не стоит бездумно делать любое приложение многопоточным! Как, в прочем, вообще не стоит применять какой-то (любой) инструмент бездумно. А в случае автора доппоток скорее всего нафиг не нужен! Использовать Application.ProcessMessage - самое нормальное решение, только нужно им правильно воспользоваться.
И особенно я против советов типа "Ознакомьтесь с потоками — это путь развития правильного программиста." Сначала нужно ознакомиться с базовыми знаниями, а уж потом с "расширенными".


А тут во всём соглашусь с Данкигом. Простая обычная отвёртка никогда не умрёт несмотря ни на какие изобретения шуруповертов и спецотверток, которые позволяют работать не переставляя саму отвертку в новое положение.


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

Это сообщение отредактировал(а) northener - 20.4.2012, 01:09