2. в принципе быстрее, т.к. прерывается как только найдёт.
grep -m 1 тоже прервётся на первом варианте... кроме того grep в принципе быстрее в абсолютных показателях (на счёт grep -P — хз)... но скорость тут не особо важна...
(в данном случае sed прервётся, но tar всё равно будет читать до победного. Хотя его тоже можно и остановить маской файла, и вывести посл. строку командой tail -n1).
когда умрёт grep или sed, tar тоже умрёт от SIGPIPE'а...
4.2кроме того grep в принципе быстрее в абсолютных показателях
за то я знаю: перловые регулярки требуют множество возвратов, а обычные регулярки выполняются всегда за один проход.на счёт grep -P — не знаю
не выспались? Ещё 4.2когда умрёт grep или sed, tar тоже умрёт от SIGPIPE'а...
grep имеет свою реализацию regexp, а sed использует glibc(конечно в версии sed для Windows тоже своя).
где-то тут давно уже обсуждали это с примерами и прочими повторяться лень...
ЕМНИП там выигрыш в реальном времени за счёт того что буфер у grep'а 256к против 64к у седа... и небольшой плюс в user'е за счёт мелких ухищрений вроде того, что grep ищет не все \n.
На практике, быстродействие одинаковое:
нуда... разница будет только на сферическом файле в tmpfs'е...
"умирание" echo не мешает sleep'у тормозить свои 3 сек.
SIGPIPE посылается при записи в обломанную трубу (stdout). т.к. sleep не пишет — ему, само собой, по барабану... а вот с кошкой, как и с tar -t, прекрасно срабатывает...
какой именно буфер? Если вы про ввод/вывод потоков, то он не в sed, а тот самый, который в fread(3)/fwrite(3), и если он вам не нравится, то напишитеЕМНИП там выигрыш в реальном времени за счёт того что буфер у grep'а 256к против 64к у седа...
sed вообще \n не ищет. Это для неё "конец записи", sed начинает работу с загрузки данных до первого \n, потом эти данные обрабатывает, потом результат выводит. Затем цикл повторяется. Это же текстовый редактор, а текст это список строк.и небольшой плюс в user'е за счёт мелких ухищрений вроде того, что grep ищет не все \n.
разница будет только на сферическом файле в tmpfs'е...
не только. Для sed можно любой скрипт написать, и тогда разница ощутима.
К примеру:
[console]$ echo "ABCDEFG" | sed -r 's/.*/\r&\r/;:l;s/(\r.)(.*)(.\r)/\3\2\1/;tl;s/\r//g'
GFEDCBA
[/console]
(это как rev)
Да, grep такого не умеет, потому с какой скоростью оно работает — роли не играет.
а, ну да.SIGPIPE посылается при записи в обломанную трубу (stdout). т.к. sleep не пишет — ему, само собой, по барабану... а вот с кошкой, как и с tar -t, прекрасно срабатывает...
какой именно буфер? Если вы про ввод/вывод потоков, то он не в sed, а тот самый, который в fread(3)/fwrite(3), и если он вам не нравится, то напишите
а grep использует read/write (иногда mmap) и буфер в несколько раз больше... за счёт этого сильно снижается количество системных вызовов... а если read читает из tmpfs, то экономия получается реальная.
за счёт того что буфер у grep'а 256к против 64к у седа
с размерами я тут налажал... у меня 32к и 4к соответственно.
sed вообще \n не ищет. Это для неё "конец записи", sed начинает работу с загрузки данных до первого \n, потом эти данные обрабатывает, потом результат выводит. Затем цикл повторяется. Это же текстовый редактор, а текст это список строк.
гнутый grep ищет в потоке байт, а если что-то нашёл, то только тогда ищет уже начало/конец строки...
Да, grep такого не умеет, потому с какой скоростью оно работает — роли не играет.
ну да... grep хуже потому что он grep, а не sed...
да? Очень сомневаюсь, а проверять лениво.а если read читает из tmpfs, то экономия получается реальная.
а гнутый sed ищет в потоке слово.гнутый grep ищет в потоке байт
ну да... grep хуже потому что он grep, а не sed...
просто возможности grep ограничены исключительно поиском подстроки, а эта задача не критична по производительности. Потому производительностью grep долгое время вообще не занимались, и только в последний год зачесались. А вот для sed производительность изначально важна. Потому она там и больше.
Просто никто не grep'ает tmpfs, а вот sed может сделать над одной строкой множество действий. Потому CPU для sed может оказаться узким местом, в отличие от grep.
да? Очень сомневаюсь, а проверять лениво.
вот старые тесты: grep sed perl awk - что быстрее для простых выборок
а гнутый sed ищет в потоке слово.
sed начинает работу с загрузки данных до первого \n, потом эти данные обрабатывает, потом результат выводит. Затем цикл повторяется. Это же текстовый редактор, а текст это список строк.
так определись, что sed делает? загружает строку до первого /n или целиком в свой рабочий буфер...
Эта оптимизация с \n в sed тоже имеется, причём уже много лет.
не представляю, как она приминима для чего-то кроме поиска выражений... т.е. она абсолютно бесполезна для всего остального, что делает «текстовый редактор»...
А вот про какой буфер вы говорите — я не понимаю.
рабочий буфер в который считывает read(2)...
Буфер, который внутри fread(3) имеет оптимальный размер, т.к. glibc лучше его знает, чем grep.
он имеет банальный размер страницы памяти... и оптимальный он только в том плане, что меньше было бы выделять не оптимально...
просто возможности grep ограничены исключительно поиском подстроки, а эта задача не критична по производительности. Потому производительностью grep долгое время вообще не занимались, и только в последний год зачесались.
ЛПП/4.2/белены объелись?/или что там модно сейчас писать в подобных случаях/
дисковый io нивелируется и в других случаях: например многократный grep одного файла...
вот старые тесты: grep sed perl awk - что быстрее для простых выборок
1. это очень старые тесты
2. вам там намекали на LC_ALL=C (кстати, а почему вы не экспортировали данную переменную?)
3. для таких примитивных команд никто не станет использовать sed вместо grep.
4. всё равно это всё упрётся даже в SSD, не говоря уж о HDD.
посмотрите исходник. ЕМНИП она загружает 4К или типа того в буфер не глядя на \n, а потом раскручивает RE. Я точно не помню, да и смотрел я это место лет пять назад, не знаю, как оно сейчас.так определись, что sed делает? загружает строку до первого /n или целиком в свой рабочий буфер...
ну дык sed как раз и ищет выражения. А вот "текстовый редактор" начинается когда(и если) найдёт. Для большинства строк условие(условия) не выполняется.не представляю, как она приминима для чего-то кроме поиска выражений...
рабочий буфер в который считывает read(2)...
этот рабочий буфер в версии sed образца 2007го (примерно) года составлял 50 байт, и увеличивался(удваивался) по мере необходимости. (но не уменьшался).
нет. Я как-то смотрел это место, у меня было 64К, хотя страница была 4К. Конечно сейчас (и/или в другом дистрибутиве) может быть иначе.он имеет банальный размер страницы памяти...
и оптимальный он только в том плане, что меньше было бы выделять не оптимально...
а "больше" было-бы оптимально? Если всё равно копировать надо куда-то.
дисковый io не нивелируется. Как раз наоборот: дисковый io занимает ВСЁ время работы, т.е. пока с диска читаются данные, sed/grep их успевает обработать намного быстрее. В итоге, мы имеем скорость как при обычном копировании(только загрузка CPU не 0.1%, а 0.2%).дисковый io нивелируется и в других случаях: например многократный grep одного файла...
2. вам там намекали на LC_ALL=C (кстати, а почему вы не экспортировали данную переменную?)
это, действительно, _очень_ старые тесты...
этот рабочий буфер в версии sed образца 2007го (примерно) года составлял 50 байт, и увеличивался(удваивался) по мере необходимости. (но не уменьшался).
это уже куда помещается строка для того, чтобы над ней магию творить...
ну дык sed как раз и ищет выражения. А вот "текстовый редактор" начинается когда(и если) найдёт. Для большинства строк условие(условия) не выполняется.
поверю на слово...
а "больше" было-бы оптимально? Если всё равно копировать надо куда-то.
оптимальней c точки зрения кол-ва вызовов read(2)... ИМХО это может и даёт разницу в скорости...
дисковый io не нивелируется. Как раз наоборот: дисковый io занимает ВСЁ время работы, т.е. пока с диска читаются данные, sed/grep их успевает обработать намного быстрее. В итоге, мы имеем скорость как при обычном копировании(только загрузка CPU не 0.1%, а 0.2%).
а мне бабушка рассказывала, что после первого чтения файл с большой вероятностью он останется в кеше в оперативке, если там достаточно места...
ну куда-то в этот буфер. Там довольно-таки запутанный код, я в нём когда-то разобрался, но сейчас уже не помню подробностей.это уже куда помещается строка для того, чтобы над ней магию творить...
просто код sed написан исходя именно из этого соображения.поверю на слово...
может и так.оптимальней c точки зрения кол-ва вызовов read(2)... ИМХО это может и даёт разницу в скорости...
при чём тут это?а мне бабушка рассказывала, что после первого чтения файл с большой вероятностью он останется в кеше
при чём тут это?
Ещё раз: файл читается с HDD/SSD первый раз. Его нет в кеше.
восстановлю ещё раз логику беседы...
дисковый io нивелируется и в других случаях: например многократном grep одного файла...
дисковый io не нивелируется. Как раз наоборот: дисковый io занимает ВСЁ время работы...
а мне бабушка рассказывала, что после первого чтения файл с большой вероятностью он останется в кеше
при чём тут это?
Ещё раз: файл читается с HDD/SSD первый раз. Его нет в кеше.
PS: странные результаты в вашем тесте скорее всего объясняются тем, что grep как-то смогла mmap'нуть файл, а вот все остальные утилиты файл честно копировали в свой буфер, и именно на это потратили время. А время именно обработки регулярки настолько ничтожное, что в тесте даже не заметно.
гм... хоть и сомневаюсь, но может быть...
когда-то гнутый grep по-дефолту mmap'ил файлы... не помню, почему когда это отключили... т.к. при тестировании я версий не указал, то годать об этом можно только по cvs'у гентушного дерева...
гм... хоть и сомневаюсь, но может быть...
когда-то гнутый grep по-дефолту mmap'ил файлы... не помню, почему это отключили... т.к. при тестировании я версий не указал, то годать об этом можно только по cvs'у гентушного дерева...
Прошлой зимой на форуме был активен топик Правка/поиск текста
На основе его я наговнокодил wxLua Dictionary Search
И тогда же провел небольшое сравнение wxLua Dictionary Search
Тест проводился следующий: поиск по трем словарям (100+ мбайт в сумме, самый маленький 5000+ строк, самый крупный 123000+ строк), поисковой запрос должен был игнорировать регистр. Быстрее всех искал перл, он за полсекунды находил результат. Моя быдлореализация на Lua давала результат за 4 секунды (кстати, по ссылке этого нет, но потом проверял с LuaJIT, с ней в два раза быстрей), grep давал результат за 6 секунд.
Естественно, может если сравнивать скорость grep при наличии одного входного файла, результат будет совсем другой.
И это при том, что маска у Lua и Perl предусматривала больше совпадений, чем у grep'а
з.ы. я не претендую на истину, просто были вот такие наблюдения, может сам что не так сделал тогда
зачем вы постоянно переводите разговор на кеширование? Я про него тоже знаю. И кеширование AFAIK работает совершенно одинаково, что для sed, что для grep. Да и какая разница? Ведь ни кому не придёт в голову грепать кешированный файл, зачем это надо?восстановлю ещё раз логику беседы...
это потому, что в перловке по дефолту отключено UTF-8, а в sed по дефолту включено. Если и там и там включить(или выключить), то сравняются.поисковой запрос должен был игнорировать регистр. Быстрее всех искал перл
зачем вы постоянно переводите разговор на кеширование?
дык, про остальное вроде договорились...
. Да и какая разница? Ведь ни кому не придёт в голову грепать кешированный файл, зачем это надо?
бывают житейские ситуации, когда это необходимо так делают... например, поиск конкретных строк в несколькогиговом логе... а после того, как грепнул один раз и он выдал постынку, надо скормить это wc или less'у...
Естественно, может если сравнивать скорость grep при наличии одного входного файла, результат будет совсем другой.
это ещё почему?
з.ы. я не претендую на истину, просто были вот такие наблюдения, может сам что не так сделал тогда
без попытки воспроизвести результаты пока даже не возьмусь интерпретировать их...
и на е бывает, и наё…бывают житейские ситуации
руки кривые, ибо очевидно, что вывод Over9000 строк в терминал абсолютно бесполезен. Ну да, ладно, бывает такая беда.поиск конкретных строк в несколькогиговом логе... а после того, как грепнул один раз и он выдал постынку
это ещё почему?
Потому что я лично сам не проверял, а значит и утверждать не могу каким будет результат при других входных данных - таким же или другим. Ключевые слова в том предложении были "может если ...".
Потому что я лично сам не проверял, а значит и утверждать не могу каким будет результат при других входных данных - таким же или другим. Ключевые слова в том предложении были "может если ...".
да... чего-то я не так прочитал... подумал, что там утверждение...
Суть в том, что что-бы там внутри sed/grep не было, файл они обрабатывают с такой скоростью, с какой этот файл с HDD/SSD читается. Т.е. скорость не имеет значения.
вообще говоря, нет. не стоит забывать о случаях, когда файл уже прочитан. А в остальных 9 из 10 — да, скорость диска много меньше скорости потрахов...
да, тут ещё можно поспорить о том, что будет в случае сверхбольших/сложных регулярок или их чрезмерного количества, как в недавней теме... но это уже отдельные темы...
руки кривые, ибо очевидно, что вывод Over9000 строк в терминал абсолютно бесполезен.
не руки кривые, а телепатиия моя слабовата... не всегда получается предвидеть, когда получится простынка, а когда нет...
2. ждать, пока less найдёт конец файла, который grep читает
less выводит по мере поступления, а не ждёт конца...
ну если он закешировался, то он маленький, и врем я его обработки значения тоже не имеет. А если он в 100Гб, то конечно имеет, но такой файл в память не влезет. Как не крути.вообще говоря, нет. не стоит забывать о случаях, когда файл уже прочитан.
это вотчина sed/perl, а может быть даже C/C++. Grep тут не при чём.да, тут ещё можно поспорить о том, что будет в случае сверхбольших/сложных регулярок или их чрезмерного количества, как в недавней теме... но это уже отдельные темы...
угу. Первый экран. А что-бы с less нормально работать(поиск, навигация, и всё остальное), конца надо дождаться.less выводит по мере поступления, а не ждёт конца...
А если он в 100Гб, то конечно имеет, но такой файл в память не влезет. Как не крути.
100 гигов текста — не жизненный пример... не представляю, когда такое может возникнуть, окромя как ситуации экологической катастрофы вызванной приступным отсутствием logrotate....
а ревльно существующие массивы, критичные к объёму 1—3Гб вполне влазят в ОП... и даже бОльшие...
это вотчина sed/perl, а может быть даже C/C++. Grep тут не при чём.
почему это?
SQL dump?100 гигов текста — не жизненный пример... не представляю, когда такое может возникнуть
но при чём тут "производительность"? Такие файлы грепаются мгновенно.а ревльно существующие массивы, критичные к объёму 1—3Гб вполне влазят в ОП... и даже бОльшие...
потому что grep умеет только искать и показывать найденное. В отличие от sed, которая умеет также обрабатывать текст.почему это?
