Привет! С праздником вас!   Как можно посчитать кол-во строк в txt файле, если я использую стринговый метод?

Это сообщение отредактировал(а) Витаминка - 27.12.2006, 06:08

aktuba спасибки   

А что будет работать быстрее этот код или тот что выше  

ivan219, зависит от размера файла. Твой вариант вобщем-то "лучше", т.к. первый вариант (stringlist) загружает весь файл в память, там парсит на отдельные строки. 
Для небольших файлов и если не надо считать много файлов оба алгоритма "одинаковые".

Хотите скорость? Тада смотрите:



Кол-во строк в файле размером 33 мегабайта считается абсолютно моментально, т.е. даже незаметно, что происходит. Однако, если нужно работать с большими файлами(болше 80 метров), то лучше читать файл участками по 64 Кб и считать в каждом кол-во переносов, иначе для файловых проекций, который я использовал в примере, ваш своп раздует до ужасных размеров

Это сообщение отредактировал(а) W4FhLF - 27.12.2006, 19:53

Да метод предложенный W4FhLF самый быстрый из 3 выше перечисленных.

Я поэксперементировал так фаил в котором 100000000 строк и размером 300000000 Байт.
Фаил такого типа:

получается  100000000 точек

Время выполнения подщёта всего 1 Секунда  на процесоре 2гГц и памяти 1Гб

Все остальные просто виснут  

Это сообщение отредактировал(а) ivan219 - 30.12.2006, 19:33

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

Да что-ты?

Ловкость рук и ни какого ассемблера("на прямую"):


PS: Да и результат более точен 

А что если вот так вот без всяких там функций? 

Girder, 



Ну убери inc ebx в конце, я на автомате поставил, суть-то не в этом.



И что это доказывает? То, что это можно было переписать на делфи понятно. Куски кода в которых очень критична скорость, я сначала пишу на ЯВУ, дизассемблирую, смотрю как оптимизировал это компилятор, если меня что-то не удовлетворяет я переписываю этот участок кода на ассемблер и сравниваю. В данном случае компилятор проиграл. 

Да что-ты? 

PS: Как раз с точностью наоборот... приведенный тобой код работает медленнее по сравнению с кодом от компилятора.

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

А то... что! Приведенный тобой алгоритм хотя бы потому не рационален, потому что постоянно заставляет переключать разрядность команды(от компилятора таже вещь присутсвует, но тем не менее он более "оптимальным" получился)!

PS: И кстати... 0A - перевод строки; 0D- возврат каретки.

Ах... да! чуть не забыл... мало преимущество, а так  

PS2: И не спрашивай... почему такой длинный код быстрее(на современных компах) - думай...! 

Добавлено @ 11:42 
На смешанном файле размером 343912250, выигрыш на AMD64(3200+) порядка 20%   

Ну только не надо говорить о рациональности по сравнению с твоим. Посмотри в дизассемблере, на одну иттерацию в твоём случае приходится два обращения к памяти и в общем случае используется 5 регистров, в моём случае обращение к памяти одно и используется 3 регистра. Поэтому в плане рациональности по сравнению с if pByte(pMemory+i)^=$0a then inc(Result); алгоритм на ассемблере удачнее. Хотя должен признать, что на практике, если не учитывать всех прочих факторов и измерить скорость с помощью GetTickCount, хотя это очень не тоно, но работают они одинаково быстро, твой алгоритм даже на 10% быстрее, но по бенчмаркам-то он проигрывает.   Ещё раз убеждаюсь в том, что архитектура современных процессоров настолько сложна, что невозможно прогнозировать скорость алгоритмов с такой точностью. Ну и кстати я не утверждал, что мой алгоритм не поддаётся дальнейшей оптимизации, наоборот 
Небольшой проигрышь в скорости в данном случае, скорее всего, объясняется тем, что оба цикла имеют размер меньший 32-64 байта, а значит могут полностью поместиться в одной линейке кеш-памяти, доступ к которой, по скорости, на порядки выше, чем доступ к оперативной памяти. Далее, ты идёшь от начала участка к концу, но как известно при запросе однойго байта из ОЗУ берётся кол-во байт равное длине линейки кеша(в зависимости от процессора 32 или 64 байта), значит следующие 32-64 иттерации процессор оперативную память не трогает. Я же иду от конца к началу, вероятнее всего процессор не может предвидеть такие ситуации и гораздо чаще обращается к ОЗУ. 

Что ты подразумеваешь под разрядностью команды? У команды нет такого понятия "разрядность", есть размер смещения и размер непосредственного операнда и как это "переключать разрядность команды" я тоже не понимаю. Выразись точнее.

Поэтому признаю, что алгоритм мой более медленный, эх... 



Обижаешь! Я думал для программистов под win32 стало уже стандартом использовать эти два служебных символа вместе.



А чего тут думать? Во-первых, если в файле кол-во строк, чья длина < 3 достаточно, то в одной иттерации можно определить сразу два(ну если без возврата каретки, то три) переноса. Во-вторых, считывается сразу машинное слово в регистр, на наших процессорах работа с DWORD'ами естественно происходит быстрее, чем с байтами и младшими частями регистров. В-третьих, сравнение происходит уже со значением регистра, а не со значением в памяти/кеше. Ну и конечно гораздо меньше кеш-промахов.

За этот алгоритм твёрдая 5+ и респект