forum.opennet.ru

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Режим отображения отдельной подветви беседы		[ Отслеживать ]

Оглавление

Выпуск утилиты GNU grep 3.4, opennews (?), 03-Янв-20, (0) [смотреть все]

Не нужно ripgrep в 3 5 быстрее , BSD_Cucks_BTFO (?), 10:05 , 03-Янв-20, (1) –8 //

А нам некуда спешить тише едешь -- дальше будешь А то грепают тута аки самолёт, A.Stahl (ok), 10:13 , 03-Янв-20, (2) +10 //

иногда надо по-быстрому в многометровом логе найти нужное событие , qqq (??), 14:39 , 03-Янв-20, (19) –1 //

многогиговом, 12345 (??), 14:56 , 03-Янв-20, (22)

Такие логи есть смысл сваливать в более специальные системы с индексированием, е, Michael Shigorin (ok), 19:50 , 03-Янв-20, (50) +2

Имхо, пока ничего лучше sawmill не придумали для этой задачи, но даже sawmill, IdeaFix (ok), 20:52 , 03-Янв-20, (55) –1

Главное настроить систему логирования на системе логирования, что бы когда она б, GentooBoy (ok), 00:32 , 04-Янв-20, (72) +1
дороговато для грепа, Anonymouss (?), 00:55 , 04-Янв-20, (75)

Тогда греп надо на электрон переписать , Аноним (20), 14:49 , 03-Янв-20, (20) +5 //

не успеюют - быстрее сделают grepd, супернуб (?), 09:22 , 06-Янв-20, (87)

Да, rg и fd - должны быть на каждой системе Fd кстати сделан поверх либы walkdi, Wilem (?), 12:08 , 03-Янв-20, (7) +1
riggrep написан на rust, не учитывает особенности unicode u ss - 223 и не п, bircoph (ok), 14:08 , 03-Янв-20, (12) +5 //

Объясни по-подробнее про особенности utf8, что не так , Wilem (?), 14:25 , 03-Янв-20, (16) –1 //

Я не знаю, что он имел в виду, но венда тоже не умеет в utf8 По-моему я даже в , Аноним (21), 14:51 , 03-Янв-20, (21)

https snipboard io 5E9mRX jpg, Wilem (?), 15:02 , 03-Янв-20, (23) –1

Там свой особенный утф8, мало общего имеющий со стандартом Дело не в том, что о, Аноним (21), 15:28 , 03-Янв-20, (25) –1

А что за символы с которыми крешится или которые несовместимы Прям сейчас бы оп, Wilem (?), 15:45 , 03-Янв-20, (28) –1

Я не помню, какие именно, но даже в википедии емнип было написано в японской 1, Аноним (21), 16:00 , 03-Янв-20, (30)

UTF-8 не нужен при наличии полноценного юникода Квест угадай сколько байтов по, Аноним (67), 22:33 , 03-Янв-20, (67) –3

Полноценный - это какой UTF-32 Ну да, там есть небольшой запас, чтобы на это з, Аноним (21), 22:57 , 03-Янв-20, (69)

В винде вроде двухбайтовый UCS2 фигурировал PS полноценный , ага , Michael Shigorin (ok), 23:09 , 03-Янв-20, (70)
В UTF-8 в теории символ может до 6 байт весить, это сильно лучше или как , Аноним (83), 23:08 , 04-Янв-20, (83)

Очень в теории, текущий лимит 4 байта из соображений совместимости И всяко лучш, Аноним (21), 23:23 , 04-Янв-20, (84)

Угу, то ли дело греп, на который еще не так давно лет 6 назад любители вставит, Аноним84701 (ok), 15:28 , 03-Янв-20, (26) –2 //

В спеке на утф-8 сказано, что Eszett приравнивается к ss Я такого найти не см, Wilem (?), 15:42 , 03-Янв-20, (27)

Мне лень смотреть Ведь это не я писал о том, что ripgrep не учитывает особенно, Аноним84701 (ok), 17:29 , 03-Янв-20, (36) +4

Ну вот, опять восхищаюсь Вашими тщательностью и кругозором - Был бы рад знакомс, Michael Shigorin (ok), 19:44 , 03-Янв-20, (48)

Просто приходится много общаться с немецкоязычными, поэтому и разбираться с выве, Аноним84701 (ok), 20:08 , 03-Янв-20, (52) +1

Период, а не переод , Anonymoustus (ok), 11:46 , 05-Янв-20, (85)

У него беда с докой Он понимает опции -e, -f, -l, -n, -s, -q, -v , Аноним (13), 14:18 , 03-Янв-20, (13) //

rg --helpДовольно подробная , Wilem (?), 14:23 , 03-Янв-20, (15) –1
https pastebin com N7xZyMnD, Wilem (?), 14:28 , 03-Янв-20, (17) –1

Я люблю Rust и юзаю rg, но вот такие провокационные комментарии мне совсем не нр, Аноним (18), 14:31 , 03-Янв-20, (18) //

Тезис был grep - не нужен Если ты считаешь, что это не так, объясни - зачем ну, Wilem (?), 15:04 , 03-Янв-20, (24) –2 //

Я держусь позиции, что Rust должен будет заменить C, особенно когда до конца реш, Аноним (18), 15:51 , 03-Янв-20, (29) –2

Греп обязательно должен быть в стандартных поставках потому, что многие скрипты , Wilem (?), 16:02 , 03-Янв-20, (32) –1

В целом согласен, но все же поскольку от GNU grep пока никуда не убежишь, это хо, Аноним (18), 16:08 , 03-Янв-20, (33)

Я бы сказал -- тождественно равен нулю Особенно для тех, которые заморачиваютс, Michael Shigorin (ok), 19:41 , 03-Янв-20, (47) –1
Рано или поздно что-то заменит C Но почему вы уверены, что это будет Rust, а не, Аноним (61), 21:53 , 03-Янв-20, (61) +1

Возможно и не Rust Не хотелось бы, чтобы Verona, едва ли ситуация с именем в та, Аноним (18), 22:25 , 03-Янв-20, (65) –2

А конструкции типа более лучшая альтернатива грепать умеет Если нет,, Аноним (21), 17:59 , 03-Янв-20, (38)

Очевидно умеет, странный вопрос И сделает это намного быстрее , Аноним (18), 18:47 , 03-Янв-20, (40) –1

Поставил, пришлось скачать 15мб раст у меня был Установка заняла 5 минут, экз, Аноним (21), 19:13 , 03-Янв-20, (43) +2

Угу, здорово Я ведь тоже вам могу сейчас случайных чиселок набросать, но занима, Аноним (18), 19:31 , 03-Янв-20, (44) –2

Вы бы циферками и ответили, а не детским садом , Michael Shigorin (ok), 19:36 , 03-Янв-20, (45) +1

Я не большой специалист в данном вопросе, чтобы анализировать эти чиселки тем б, Аноним (18), 19:45 , 03-Янв-20, (49) –1

это детский сад, увы Нет, я тоже чаще меряю на глазок , чем отмеряю микром, Michael Shigorin (ok), 19:54 , 03-Янв-20, (51)

С высоты птичьего полета, безо всякой теории погрешностей У меня не SSD, как у , Аноним (18), 20:34 , 03-Янв-20, (54) –1

А чё, можете сами проверить Вот вам данные http ftp freedb org pub freedb fre, Аноним (21), 21:33 , 03-Янв-20, (60)

Вот вам более реальное тестирование Это всё, что нужно знать о хипстоподелках и, Аноним (21), 21:07 , 03-Янв-20, (58)

Ну знаю, у меня не было мнения Но я считаю, что должно быть сопоставимо с си, а, Аноним (21), 21:03 , 03-Янв-20, (57) –1

Ни разу не удавалось подобного результата добиваться, у меня всегда rg работал л, Аноним (18), 22:15 , 03-Янв-20, (63) –1
Честно говоря, не представляю, как вы такого добились и уже подумываю забрать св, Аноним (18), 00:20 , 04-Янв-20, (71)

В брошу свои чиселки с tmpfs, лучший результат 4 запусков code time rg -c , анонн. (?), 01:19 , 04-Янв-20, (77)

Вот потому я и не хотел играть в эти идиотские чиселки Всегда можно подобрать у, Аноним (18), 01:36 , 04-Янв-20, (79)

1 файл это не спортивно Лично мне нравится руст, но не нравится результат где п, Аноним (21), 01:34 , 04-Янв-20, (78)

Ну вот вам code find usr src -type f 124 wc -l 83928du -sh usr src2,5G u, анонн. (?), 00:37 , 04-Янв-20, (73) +2

В догонку rg --version , анонн. (?), 00:40 , 04-Янв-20, (74)
ok, grep ядра без кэшей , 0 5 мб памяти в пике, 2 5 shared code 2863real 0m1, Аноним (21), 01:13 , 04-Янв-20, (76)

Чего-чего, но падений я еще не видел Наверное, потому что не влезет в tmpfs, да , анонн. (?), 01:52 , 04-Янв-20, (80)

Мне Раст интересен Но растаманы оталкивают тем что серят в адрес Юникса, ГНУ и , Аноним (-), 18:20 , 03-Янв-20, (39) +4 //

В семье не без разнообразия Не знаю, кто занимается такими глупостями, но не, Аноним (18), 18:57 , 03-Янв-20, (41) +1

Что за глупый вопрос Смысл родительского коммента сводится к не нужно , какая , Ordu (ok), 22:00 , 03-Янв-20, (62)

Теперь осталось добавить опцию --cancel-no-ignore-case false , Аноним (3), 10:39 , 03-Янв-20, (3) +11 //

--switch-off-disable-cancel-no-ignore-case false true , Аноним (9), 13:49 , 03-Янв-20, (9) +1 //

остаётся только значение по умолчанию сделать рандомным, Аноним (9), 13:50 , 03-Янв-20, (10) +1

А может кто-то поделиться с домохозяйкой http www gnu org software grep manual, Аноним (4), 11:01 , 03-Янв-20, (4) –3 //

оно https www opennet ru man shtml topic grep russian 0 category submit F0 C, JL2001 (ok), 12:18 , 03-Янв-20, (8)
https www google com search q grep D0 B4 D0 BB D1 8F D1 87 D0 B0 D0 B9 D0 BD, iCat (ok), 14:23 , 03-Янв-20, (14) –1

не знаю как гулугулу , а тындекс выдал по запросу man grep в первую очередь н, San (??), 11:34 , 03-Янв-20, (5) +1 //

не знаю, что за тындэкс, но гугл первой ссылкой выдаёт на русском а ещё знаю, г, Аноним (9), 13:51 , 03-Янв-20, (11) –1

хотелось бы исключения файлов по маскам или по крайней мере упрощение, manster (ok), 16:02 , 03-Янв-20, (31) –1 //

Почитай про гну-тулбокс, и не проси глупостей Чтобы выбирать файлы или исключат, Ordu (ok), 17:16 , 03-Янв-20, (34) //

мне в git grep нужно, manster (ok), 17:19 , 03-Янв-20, (35) –2 //

git-grep 1 до pathspec дочитайте - , Michael Shigorin (ok), 19:39 , 03-Янв-20, (46)

Заметил, что режим угадываний малоэффективен Разумеется в курсе, что git grep 1, manster (ok), 20:11 , 03-Янв-20, (53) –1

cat bashrcfunction git-grep git grep -- SOURCE_FILES_PATTERNS D, Ordu (ok), 21:24 , 03-Янв-20, (59) +1

Благодарю, мне представляется это неплохим решением, но не очень понятно как это, manster (ok), 22:19 , 03-Янв-20, (64)

Если я правильно понимаю, то как-то так cat emacs setq helm-git-grep-pathsp, Ordu (ok), 22:48 , 03-Янв-20, (68) +1

не, не делай ТАК Прочитай, все же, пока не запретили как неполиткорректную писан, . (?), 17:37 , 03-Янв-20, (37) –6 //

Хозяйке на заметку этот же организм в соседней теме про CCC бредил полониевым н, Michael Shigorin (ok), 18:58 , 03-Янв-20, (42) –2
Не, я не буду читать Кернигана, только для того, чтобы выяснить что-нибудь в сти, Ordu (ok), 20:56 , 03-Янв-20, (56) –1

Луговский похожую дорожку проходил несколько раньше -- возможно, Вам бы оказалос, Michael Shigorin (ok), 22:25 , 03-Янв-20, (66) –2

Что есть ГНУ Хорошую вещь ГНУ не назовут , Аноним (86), 16:28 , 05-Янв-20, (86)

Сообщения [Сортировка по времени | RSS]

24. "Выпуск утилиты GNU grep 3.4" –2 +/–

Сообщение от Wilem (?), 03-Янв-20, 15:04

Тезис был: grep - не нужен. Если ты считаешь, что это не так, объясни - зачем нужен grep при наличии лучшей альтернативы?

Ответить | Правка | Наверх | Cообщить модератору

29. "Выпуск утилиты GNU grep 3.4" –2 +/–

Сообщение от Аноним (18), 03-Янв-20, 15:51

Я держусь позиции, что Rust должен будет заменить C, особенно когда до конца решатся все проблемы llvm с алиасингом и Rust станет в целом быстрее, чем C. Но по банальной реакции аудитории opennet на Rust видно, что сообщество пока к этому не готово (в англоязычном сообществе примерно такая же ситуация, только без такого количества агрессии).
Но на данный момент конкретно с rg я вижу такие очевидные проблемы:
1. rg не POSIX-совместим. Это не то чтобы плохо, стандарту POSIX уже сколько лет и пора бы двигаться дальше, но пока это проблема. В целом, это решаемо банальным созданием POSIX-совместимой обертки.
2. llvm пока поддерживает не так много архитектур
3. Rust пока что вызвает много недоверия у сообщества, потому шанс того, что мейнтейнеры текущих популярных дистрибутивов зареплейсят grep на rg в качестве стандартной утилиты довольно мал. Соотвественно на данный момент важно, чтобы GNU grep существовал хотя бы на аппарате жизнеобеспечения.

Ответить | Правка | Наверх | Cообщить модератору

32. "Выпуск утилиты GNU grep 3.4" –1 +/–

Сообщение от Wilem (?), 03-Янв-20, 16:02

Греп обязательно должен быть в стандартных поставках потому, что многие скрипты его используют. Но самому пользоваться грепом не вижу смысла. Также, как и find-ом (fd сильно быстрее). Я их оба два закатал в базовый докеровский образ на котором остальные все образы на работе базируются. Очень удобно.
Что касается пакетов в дистрибутивах, это вообще по-барабану - есть ripgrep в пакетах или нет. cargo install ripgrep если для личных нужд. А для рабочих есть ansible или образы для поддержания единства конфигурации машин.

Ответить | Правка | Наверх | Cообщить модератору

33. "Выпуск утилиты GNU grep 3.4" +/–

Сообщение от Аноним (18), 03-Янв-20, 16:08

В целом согласен, но все же поскольку от GNU grep пока никуда не убежишь, это хорошо, что в нем хотя бы баги латают.

Ответить | Правка | Наверх | Cообщить модератору

47. "Выпуск утилиты GNU grep 3.4" –1 +/–

Сообщение от Michael Shigorin (ok), 03-Янв-20, 19:41

> 3. Rust пока что вызвает много недоверия у сообщества, потому шанс
> того, что мейнтейнеры текущих популярных дистрибутивов зареплейсят
> grep на rg в качестве стандартной утилиты довольно мал.
Я бы сказал -- тождественно равен нулю.  Особенно для тех, которые заморачиваются не-x86 (и ещё и не-arm) -- там "помножить на хреновую поддержку архитектур".

Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

61. "Выпуск утилиты GNU grep 3.4" +1 +/–

Сообщение от Аноним (61), 03-Янв-20, 21:53

>Я держусь позиции, что Rust должен будет заменить C,
Рано или поздно что-то заменит C. Но почему вы уверены, что это будет Rust, а не, например, Verona или подмножество betterC языка D?
>особенно когда до конца решатся все проблемы llvm с алиасингом и Rust станет в целом быстрее, чем C
А как решится проблема с запретом использования названия Rust в альтернативных реализциях? Кажется, уже кто-то наступал на подобные грабли, не Sun ли это был?

Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

65. "Выпуск утилиты GNU grep 3.4" –2 +/–

Сообщение от Аноним (18), 03-Янв-20, 22:25

Возможно и не Rust. Не хотелось бы, чтобы Verona, едва ли ситуация с именем в таком случае будет лучше, а то может и не в одном имени проблемы будут, это же microsoft.
По крайней мере, даже если с Rust что-то пойдет не так, скорее всего тот язык, который таки прочно заменит C, будет как минимум использовать многие идеи и наработки из Rust.
Просто пока у Rust больше всех шансов. К D никто интереса не проявляет, да и он на самом деле не решает такого количества проблем, как Rust, да и комбинация ооп и функционального программирования в Rust очень здорово работает, как по мне. Насколько знаю, автор D даже начал делать borrow checker для своего языка, чтобы это исправить. Может что-то из этого и выйдет. Про Better C мало слышал, чуть позже почитаю.

Ответить | Правка | Наверх | Cообщить модератору

38. "Выпуск утилиты GNU grep 3.4" +/–

Сообщение от Аноним (21), 03-Янв-20, 17:59

А конструкции типа (\[.*?\]+) более лучшая альтернатива грепать умеет? Если нет, то сами знаете, куда её запихнуть вместе с авторами, потому что это совсем не альтернатива.

Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

40. "Выпуск утилиты GNU grep 3.4" –1 +/–

Сообщение от Аноним (18), 03-Янв-20, 18:47

Очевидно умеет, странный вопрос. И сделает это намного быстрее.

Ответить | Правка | Наверх | Cообщить модератору

43. "Выпуск утилиты GNU grep 3.4" +2 +/–

Сообщение от Аноним (21), 03-Янв-20, 19:13

>намного быстрее
Поставил, пришлось скачать 15мб (раст у меня был). Установка заняла 5 минут, экзешник 4.5 мегабайта (греп 0.2 мегабайта - отработает пока оно считается в память!).
По факту, результаты следующие.
grep(на холодную без кэшей):
real    0m0.009s
user    0m0.001s
sys     0m0.002s
rg(на холодную без кэшей):
real    0m0.038s
user    0m0.002s
sys     0m0.005s
grep(повторный запуск подряд):
real    0m0.002s
user    0m0.001s
sys     0m0.001s
rg(повторный запуск подряд):
real    0m0.004s
user    0m0.003s
sys     0m0.001s

Данных было 15 байт, система на ссд. Вывод: ваша информация - очередной фейк.

Ответить | Правка | Наверх | Cообщить модератору

44. "Выпуск утилиты GNU grep 3.4" –2 +/–

Сообщение от Аноним (18), 03-Янв-20, 19:31

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

Ответить | Правка | Наверх | Cообщить модератору

45. "Выпуск утилиты GNU grep 3.4" +1 +/–

Сообщение от Michael Shigorin (ok), 03-Янв-20, 19:36

Вы бы циферками и ответили, а не детским садом.

Ответить | Правка | Наверх | Cообщить модератору

49. "Выпуск утилиты GNU grep 3.4" –1 +/–

Сообщение от Аноним (18), 03-Янв-20, 19:45

Я не большой специалист в данном вопросе, чтобы анализировать эти чиселки (тем более не имея на руках тестовых данных, что делает ситуацию еще более глупой). Все, что я могу сказать - на моей машине rg работает во много раз быстрее.
Обращаясь и к вам, и к остальным читающим. Не слушайте ни меня, ни господина с чиселками - поставьте rg на свою машину и протестируйте на своих реальных задачах. Было бы очень глупо, если бы вы сейчас прочтитали господина с чиселками, вам понравилось его мнение (ведь конечно, Rust ничего не может и пишут на нем глупые хипстеры), а в итоге оказаться неправым, верно?

Ответить | Правка | Наверх | Cообщить модератору

51. "Выпуск утилиты GNU grep 3.4" +/–

Сообщение от Michael Shigorin (ok), 03-Янв-20, 19:54

> Все, что я могу сказать -
...это детский сад, увы.  Нет, я тоже чаще "меряю на глазок", чем отмеряю микрометром [и отрубаю топором], но это всё же осознавать надо.
> Обращаясь и к вам, и к остальным читающим. Не слушайте ни меня,
> ни господина с чиселками - поставьте rg на свою машину
Перечитайте, пожалуйста, #12 и подскажите, где взять rust для e2k.  Моя основная рабочая машина именно на этой архитектуре.
PS: если "чиселки" не разобрали -- хотя бы отгрепав глазами(sic!) по real -- то главная из них там была 15 (та, что в последней строчке), как мне кажется.  По сути это измерение скорости запуска, а для оценки самой молотилки стоило бы погонять на -F разной длины и регэксах разной заковыристости по массивам данных от единиц байт (как там) до хотя бы мегабайт.  Если интересно -- ну так займитесь же, заодно можно теорию погрешностей подтянуть или вовсе открыть для себя :-)

Ответить | Правка | Наверх | Cообщить модератору

54. "Выпуск утилиты GNU grep 3.4" –1 +/–

Сообщение от Аноним (18), 03-Янв-20, 20:34

С высоты птичьего полета, безо всякой теории погрешностей. У меня не SSD, как у господина с чиселками - у меня зашифрованный раздел на жестком диске, и на нем я наблюдаю значительную разницу. И чиселками я бросаться не буду, потому что числелки на каких-то непонятных данных, на чьей-то чужой машине со своей конфигурацией, в чем-то убеждают, мне кажется, только не слишком далеких людей.
> где взять rust для e2k.
Архитектура довольно молодая, почему она уже обязана поддерживаться llvm? Прочитал, что у вас есть двоичная трансляция из x86 - можете с ней попробовать. Я не то чтобы евангелист llvm - лучше бы у Rust был свой бекенд. Но пока как есть.

Ответить | Правка | Наверх | Cообщить модератору

60. "Выпуск утилиты GNU grep 3.4" +/–

Сообщение от Аноним (21), 03-Янв-20, 21:33

>непонятных данных
А чё, можете сами проверить. Вот вам данные http://ftp.freedb.org/pub/freedb/freedb-complete-20191203.ta... и вот вам текст, который нужно извлечь во всех файлах: '(\[.*?\]+)'
Теперь если скажете, какие ключи надо скормить rg, тобы тот отработал сопоставимо с grep -RPo * (и желательно выдал те же данные в том же формате), я признаю, что раст имеет право на существование.

Ответить | Правка | Наверх | Cообщить модератору

58. "Выпуск утилиты GNU grep 3.4" +/–

Сообщение от Аноним (21), 03-Янв-20, 21:07

Вот вам более реальное тестирование. Это всё, что нужно знать о хипстоподелках и восторженных отзывах в интернете.
https://www.opennet.ru/openforum/vsluhforumID3/119373.html#57

Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

57. "Выпуск утилиты GNU grep 3.4" –1 +/–

Сообщение от Аноним (21), 03-Янв-20, 21:03

> Угу, здорово. Я ведь тоже вам могу сейчас случайных чиселок набросать, но
> заниматься этим я, конечно, не буду, потому что это детский сад.
> Если бы вы действительно хотели выяснить правду, а не подтвердить для себя
> собственное мнение, вы бы серьезно изучили вопрос, провели бы много разных
> тестов и скорее всего сюда бы ничего не написали.
Ну знаю, у меня не было мнения. Но я считаю, что должно быть сопоставимо с си, а не в 4 раза медленней (тем более, если речь идёт об использовании в скриптах, а не о разборе гигабайтов текста).
Пытаюсь придумать тестирование с другим тестовым набором данных (где я возьму гигабайт текста?), но пока не получается и результаты выглядят ещё хуже для противников гну.
Хорошо, реальный юзкейс. Грепнул 1.1гб текста/1100000 файлов (сущий пустяк, в принципе, во всяком случае для меня и моих данных) и чёт совсем  грустно стало. В общем, прекращайте фейкомётить.
rg:
real    61m38.956s
user    0m34.536s
sys     1m1.371s
grep:
real    2m44.097s
user    0m11.746s
sys     0m24.306s

Во время работы рг потреблял 200+ мб оперативки (уже несколько дико для применения в скриптах), греп всего 30мб. А если его тысячу раз в секунду вызывать? Ведь чем больше футпринт, тем больше сайд эффектов при использовании выплывает.
Зачем он спавнит кучу тредов, кстати? Ведь всё равно значительно быстрее не будет, а на случайном доступе просадки только такие. Выглядит, как типичная хипстоподелка каких-то школьников. Не то, чтобы это было плохо само по себе, но вот то, как вы о ней отзываетесь... И это будет конкурировать с гну греп? Вы серьёзно? Посмотрите на цифры ещё раз: менее 3х минут и более 60...

Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

63. "Выпуск утилиты GNU grep 3.4" –1 +/–

Сообщение от Аноним (18), 03-Янв-20, 22:15

Ни разу не удавалось подобного результата добиваться, у меня всегда rg работал лучше. Что ж, значит ripgrep еще не так хорош и ему есть над чем работать, все же GNU grep куда более зрелая тула. Попробую воспроизвести что-то подобное у себя. Пока не очень получилось.

Ответить | Правка | Наверх | Cообщить модератору

71. "Выпуск утилиты GNU grep 3.4" +/–

Сообщение от Аноним (18), 04-Янв-20, 00:20

Честно говоря, не представляю, как вы такого добились и уже подумываю забрать свои слова назад. Скорее всего проблема в количестве файлов - на огромном числе файлов я еще не проверял.
Я зарекался чиселки кидать, но ладно. Нашел рандомные логи http://www.almhuette-raith.at/apache-log/access.log (906M)
> time rg '(\[.*?\]+)' access.log | wc -l
4595960
real    0m1.306s
user    0m1.206s
sys    0m0.577s
> time grep -P '(\[.*?\]+)' access.log | wc -l
4595960
real    0m2.329s
user    0m2.101s
sys    0m0.949s
Больше всего отличился ag:
> time ag '(\[.*?\]+)' access.log | wc -l
4595960
real    0m22.608s
user    0m22.472s
sys    0m0.986s
После я рандомным образом изменил паттерн.
> time rg '(\[.*?\]+).*test' test.log | wc -l
6302
real    0m0.266s
user    0m0.203s
sys    0m0.072s
Ни для grep, ни для ag я результата дождаться не смог. Не знаю, с чем это связано (скорее всего с этим: https://mariusschulz.com/blog/why-using-the-greedy-in-regula... - потому вдвойне забавно, что rg это спокойно прожевал), но сейчас нет возможности доводить эксперимент до конца.

Может хватит обзывать "школьными хипстерскими поделками" все, что вам лично не нравится по идеологическим причинам? Потому что лично вы себя ведете как самый обыкновенный школьник-задира.

Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

77. "Выпуск утилиты GNU grep 3.4" +/–

Сообщение от анонн. (?), 04-Янв-20, 01:19

> Я зарекался чиселки кидать, но ладно. Нашел рандомные логи http://www.almhuette-raith.at/apache-log/access.log
> (906M)
(В)брошу свои чиселки:
>> time rg '(\[.*?\]+)' access.log | wc -l
> 4595960
> real 0m1.306s
> user 0m1.206s
> sys 0m0.577s
>> time grep -P '(\[.*?\]+)' access.log | wc -l
> 4595960
> real 0m2.329s
> user 0m2.101s
> sys 0m0.949s
с tmpfs, лучший результат 4 запусков

% time rg -c '(\[.*?\]+)' access.log
4596036
rg -c '(\[.*?\]+)' access.log  1,46s user 0,17s system 99% cpu 1,632 tota
% time rg -c -j1 '(\[.*?\]+)' access.log
4596036
rg -c -j1 '(\[.*?\]+)' access.log  1,46s user 0,15s system 99% cpu 1,607 total
time /usr/local/bin/grep -cP '(\[.*?\]+)' access.log
4596036
/usr/local/bin/grep -cP '(\[.*?\]+)' access.log  3,53s user 0,28s system 99% cpu 3,813 total
> Ни для grep, ни для ag я результата дождаться не смог. Не
> знаю, с чем это связано (скорее всего с этим: https://mariusschulz.com/blog/why-using-the-greedy-in-regula...
> - потому вдвойне забавно, что rg это спокойно прожевал), но сейчас
> нет возможности доводить эксперимент до конца.
Тут уже находили анти-паттерн для rg:

seq 100000000 > fstfile
time rg -ic 1 fstfile
47400465
rg -ic 1 fstfile  5,10s user 0,13s system 99% cpu 5,237 total
time /usr/local/bin/grep -ic 1 fstfile
47400465
/usr/local/bin/grep -ic 1 fstfile  4,28s user 0,35s system 99% cpu 4,640 total

time /usr/local/bin/grep -ic "^1" fstfile
11111113
/usr/local/bin/grep -ic "^1" fstfile  3,02s user 0,33s system 99% cpu 3,351 total
time rg -ic "^1" fstfile
11111113
rg -ic "^1" fstfile  7,77s user 0,24s system 99% cpu 8,019 total

Но это уж совсем синтетика - стоит добавить пару знаков и разница уходит:

time rg -ic "^12" fstfile
11111
rg -ic "^12" fstfile  1,83s user 0,19s system 99% cpu 2,020 total
time /usr/local/bin/grep -ic "^12" fstfile
11111
/usr/local/bin/grep -ic "^12" fstfile  2,69s user 0,32s system 99% cpu 3,017 total

Удивительно правда, что у здешнего анонима _все_ оказалось антипаттерном, да еще и c разницей на порядки.

Ответить | Правка | Наверх | Cообщить модератору

79. "Выпуск утилиты GNU grep 3.4" +/–

Сообщение от Аноним (18), 04-Янв-20, 01:36

> Удивительно правда, что у здешнего анонима _все_ оказалось антипаттерном, да еще и c разницей на порядки.
Вот потому я и не хотел играть в эти идиотские чиселки. Всегда можно подобрать удобное окружение и подходящие данные, для которых чиселки какие надо получатся. Для такого инструмента как grep, в конечном счете все определяет только личная статистика использования на повседневных задачах. Моя такова, что на моих задачах и на моих машинах rg выигрывает.
Но раз уж я влез в эту глупость, все-таки проверил grep и ag:
> time grep -P '(\[.*?\]+).*test' test.log | wc -l
6302
real    9m2.752s
user    9m2.289s
sys    0m0.080s
> time ag '(\[.*?\]+).*test' test.log | wc -l
6302
real    8m34.161s
user    8m33.436s
sys    0m0.100s

Ответить | Правка | Наверх | Cообщить модератору

78. "Выпуск утилиты GNU grep 3.4" +/–

Сообщение от Аноним (21), 04-Янв-20, 01:34

1 файл это не спортивно. Лично мне нравится руст, но не нравится результат где примитивная утилита сливает в 20 раз на типичном юзкейсе.

Ответить | Правка | К родителю #71 | Наверх | Cообщить модератору

73. "Выпуск утилиты GNU grep 3.4" +2 +/–

Сообщение от анонн. (?), 04-Янв-20, 00:37

> Хорошо, реальный юзкейс. Грепнул 1.1гб текста/1100000 файлов (сущий пустяк, в принципе,
> во всяком случае для меня и моих данных) и чёт совсем
>  грустно стало. В общем, прекращайте фейкомётить.
Ну вот вам:

find /usr/src -type f |wc -l
   83928
du -sh /usr/src
2,5G    /usr/src

результат третьего запуска греп (чтоб точно искать с кэша):

grep --version
grep (GNU grep) 3.3
Copyright (C) 2018 Free Software Foundation, Inc.
time /usr/local/bin/grep -RPo  '(\[.*?\]+)' /usr/src |wc -l
1093008
/usr/local/bin/grep -RPo '(\[.*?\]+)' /usr/src  8,14s user 1,85s system 99% cpu 9,995 total
wc -l  0,12s user 0,00s system 1% cpu 9,994 total
time rg -uuuo '(\[.*?\]+)' /usr/src |wc -l
1093006
rg -uuuo '(\[.*?\]+)' /usr/src  3,22s user 3,22s system 354% cpu 1,818 total
wc -l  0,10s user 0,22s system 17% cpu 1,815 total

в один тред

% time rg -uuuo -j1 '(\[.*?\]+)' /usr/src |wc -l
1093006
rg -uuuo -j1 '(\[.*?\]+)' /usr/src  2,02s user 1,70s system 99% cpu 3,728 total
wc -l  0,09s user 0,02s system 2% cpu 3,726 total

Потребление памяти: 18МБ RES.
Похоже кто-то, не будем указывать пальцем на анонима, собрал дебаг-билд и бодро с ним сравнил релиз билд grep. Ну или точные опции запуска - в студию!

Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

74. "Выпуск утилиты GNU grep 3.4" +/–

Сообщение от анонн. (?), 04-Янв-20, 00:40

В догонку:
rg --version
ripgrep 11.0.2

Ответить | Правка | Наверх | Cообщить модератору

76. "Выпуск утилиты GNU grep 3.4" +/–

Сообщение от Аноним (21), 04-Янв-20, 01:13

ok, grep ядра (без кэшей), 0.5 мб памяти в пике, 2.5 shared

2863
real    0m17.642s
user    0m4.675s
sys     0m1.727s

rg (без кэшей, упал?), 1мб памяти в пике плюс 5.5 shared

thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', src/libcore/option.rs:378:21
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
2862
real    0m18.099s
user    0m0.976s
sys     0m1.803s

в 4 потока rg

2862
real    0m5.618s
user    0m0.784s
sys     0m1.573s
Справедливости ради повторный запуск grep

real    0m5.130s
user    0m4.546s
sys     0m0.539s
повторный запуск rg

thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', src/libcore/option.rs:378:21
stack backtrace:
   0: <unknown>
   1: <unknown>
   2: <unknown>
   3: <unknown>
   4: <unknown>
   5: <unknown>
   6: <unknown>
   7: <unknown>
   8: <unknown>
   9: <unknown>
  10: <unknown>
  11: <unknown>
  12: <unknown>
  13: <unknown>
  14: <unknown>
  15: <unknown>
  16: <unknown>
  17: __libc_start_main
  18: <unknown>
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
2862
real    0m1.035s
user    0m0.540s
sys     0m0.459s

rg в 4 потока

2862
real    0m0.721s
user    0m0.559s
sys     0m0.518s
по-моему всё это множится на 0 фактом того, что данных мало и они синтетические в рамках данного "теста".
Вон я же дал датасет приближенный к реальным данным, почему не используете его? http://ftp.freedb.org/pub/freedb/freedb-complete-20191203.ta...
Ну и стоит всё же использовать hdd, на ssd вы много данных не разместите.
>дебаг-билд
нет

Ответить | Правка | К родителю #73 | Наверх | Cообщить модератору

80. "Выпуск утилиты GNU grep 3.4" +/–

Сообщение от анонн. (?), 04-Янв-20, 01:52

> rg (без кэшей, упал?), 1мб памяти в пике плюс 5.5 shared
Чего-чего, но падений я еще не видел.
> Вон я же дал датасет приближенный к реальным данным, почему не используете
> его? http://ftp.freedb.org/pub/freedb/freedb-complete-20191203.ta...
Наверное, потому что не влезет в tmpfs, да и качаться будет минут 10?
> Ну и стоит всё же использовать hdd, на ssd вы много данных не разместите.
Это мне в ящике стола ковыряться, хард искать, подключать … да и какой смысл измерять скорость чтения с диска, в который все и упрется (если оно не поместится в кэше).
>>дебаг-билд
> нет
Но билд, судя по паникам - кривоват.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру


	24. "Выпуск утилиты GNU grep 3.4"	–2 +/–
	Сообщение от Wilem (?), 03-Янв-20, 15:04
	Тезис был: grep - не нужен. Если ты считаешь, что это не так, объясни - зачем нужен grep при наличии лучшей альтернативы?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	29. "Выпуск утилиты GNU grep 3.4"	–2 +/–
	Сообщение от Аноним (18), 03-Янв-20, 15:51
	Я держусь позиции, что Rust должен будет заменить C, особенно когда до конца решатся все проблемы llvm с алиасингом и Rust станет в целом быстрее, чем C. Но по банальной реакции аудитории opennet на Rust видно, что сообщество пока к этому не готово (в англоязычном сообществе примерно такая же ситуация, только без такого количества агрессии). Но на данный момент конкретно с rg я вижу такие очевидные проблемы: 1. rg не POSIX-совместим. Это не то чтобы плохо, стандарту POSIX уже сколько лет и пора бы двигаться дальше, но пока это проблема. В целом, это решаемо банальным созданием POSIX-совместимой обертки. 2. llvm пока поддерживает не так много архитектур 3. Rust пока что вызвает много недоверия у сообщества, потому шанс того, что мейнтейнеры текущих популярных дистрибутивов зареплейсят grep на rg в качестве стандартной утилиты довольно мал. Соотвественно на данный момент важно, чтобы GNU grep существовал хотя бы на аппарате жизнеобеспечения.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	32. "Выпуск утилиты GNU grep 3.4"	–1 +/–
	Сообщение от Wilem (?), 03-Янв-20, 16:02
	Греп обязательно должен быть в стандартных поставках потому, что многие скрипты его используют. Но самому пользоваться грепом не вижу смысла. Также, как и find-ом (fd сильно быстрее). Я их оба два закатал в базовый докеровский образ на котором остальные все образы на работе базируются. Очень удобно. Что касается пакетов в дистрибутивах, это вообще по-барабану - есть ripgrep в пакетах или нет. cargo install ripgrep если для личных нужд. А для рабочих есть ansible или образы для поддержания единства конфигурации машин.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	33. "Выпуск утилиты GNU grep 3.4"	+/–
	Сообщение от Аноним (18), 03-Янв-20, 16:08
	В целом согласен, но все же поскольку от GNU grep пока никуда не убежишь, это хорошо, что в нем хотя бы баги латают.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	47. "Выпуск утилиты GNU grep 3.4"	–1 +/–
	Сообщение от Michael Shigorin (ok), 03-Янв-20, 19:41
	> 3. Rust пока что вызвает много недоверия у сообщества, потому шанс > того, что мейнтейнеры текущих популярных дистрибутивов зареплейсят > grep на rg в качестве стандартной утилиты довольно мал. Я бы сказал -- тождественно равен нулю. Особенно для тех, которые заморачиваются не-x86 (и ещё и не-arm) -- там "помножить на хреновую поддержку архитектур".
	Ответить \| Правка \| К родителю #29 \| Наверх \| Cообщить модератору


	61. "Выпуск утилиты GNU grep 3.4"	+1 +/–
	Сообщение от Аноним (61), 03-Янв-20, 21:53
	>Я держусь позиции, что Rust должен будет заменить C, Рано или поздно что-то заменит C. Но почему вы уверены, что это будет Rust, а не, например, Verona или подмножество betterC языка D? >особенно когда до конца решатся все проблемы llvm с алиасингом и Rust станет в целом быстрее, чем C А как решится проблема с запретом использования названия Rust в альтернативных реализциях? Кажется, уже кто-то наступал на подобные грабли, не Sun ли это был?
	Ответить \| Правка \| К родителю #29 \| Наверх \| Cообщить модератору


	65. "Выпуск утилиты GNU grep 3.4"	–2 +/–
	Сообщение от Аноним (18), 03-Янв-20, 22:25
	Возможно и не Rust. Не хотелось бы, чтобы Verona, едва ли ситуация с именем в таком случае будет лучше, а то может и не в одном имени проблемы будут, это же microsoft. По крайней мере, даже если с Rust что-то пойдет не так, скорее всего тот язык, который таки прочно заменит C, будет как минимум использовать многие идеи и наработки из Rust. Просто пока у Rust больше всех шансов. К D никто интереса не проявляет, да и он на самом деле не решает такого количества проблем, как Rust, да и комбинация ооп и функционального программирования в Rust очень здорово работает, как по мне. Насколько знаю, автор D даже начал делать borrow checker для своего языка, чтобы это исправить. Может что-то из этого и выйдет. Про Better C мало слышал, чуть позже почитаю.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	38. "Выпуск утилиты GNU grep 3.4"	+/–
	Сообщение от Аноним (21), 03-Янв-20, 17:59
	А конструкции типа (\[.*?\]+) более лучшая альтернатива грепать умеет? Если нет, то сами знаете, куда её запихнуть вместе с авторами, потому что это совсем не альтернатива.
	Ответить \| Правка \| К родителю #24 \| Наверх \| Cообщить модератору


	40. "Выпуск утилиты GNU grep 3.4"	–1 +/–
	Сообщение от Аноним (18), 03-Янв-20, 18:47
	Очевидно умеет, странный вопрос. И сделает это намного быстрее.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	43. "Выпуск утилиты GNU grep 3.4"	+2 +/–
	Сообщение от Аноним (21), 03-Янв-20, 19:13
	>намного быстрее Поставил, пришлось скачать 15мб (раст у меня был). Установка заняла 5 минут, экзешник 4.5 мегабайта (греп 0.2 мегабайта - отработает пока оно считается в память!). По факту, результаты следующие. grep(на холодную без кэшей): real 0m0.009s user 0m0.001s sys 0m0.002s rg(на холодную без кэшей): real 0m0.038s user 0m0.002s sys 0m0.005s grep(повторный запуск подряд): real 0m0.002s user 0m0.001s sys 0m0.001s rg(повторный запуск подряд): real 0m0.004s user 0m0.003s sys 0m0.001s Данных было 15 байт, система на ссд. Вывод: ваша информация - очередной фейк.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	44. "Выпуск утилиты GNU grep 3.4"	–2 +/–
	Сообщение от Аноним (18), 03-Янв-20, 19:31
	Угу, здорово. Я ведь тоже вам могу сейчас случайных чиселок набросать, но заниматься этим я, конечно, не буду, потому что это детский сад. Если бы вы действительно хотели выяснить правду, а не подтвердить для себя собственное мнение, вы бы серьезно изучили вопрос, провели бы много разных тестов и скорее всего сюда бы ничего не написали.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	45. "Выпуск утилиты GNU grep 3.4"	+1 +/–
	Сообщение от Michael Shigorin (ok), 03-Янв-20, 19:36
	Вы бы циферками и ответили, а не детским садом.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	49. "Выпуск утилиты GNU grep 3.4"	–1 +/–
	Сообщение от Аноним (18), 03-Янв-20, 19:45
	Я не большой специалист в данном вопросе, чтобы анализировать эти чиселки (тем более не имея на руках тестовых данных, что делает ситуацию еще более глупой). Все, что я могу сказать - на моей машине rg работает во много раз быстрее. Обращаясь и к вам, и к остальным читающим. Не слушайте ни меня, ни господина с чиселками - поставьте rg на свою машину и протестируйте на своих реальных задачах. Было бы очень глупо, если бы вы сейчас прочтитали господина с чиселками, вам понравилось его мнение (ведь конечно, Rust ничего не может и пишут на нем глупые хипстеры), а в итоге оказаться неправым, верно?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	51. "Выпуск утилиты GNU grep 3.4"	+/–
	Сообщение от Michael Shigorin (ok), 03-Янв-20, 19:54
	> Все, что я могу сказать - ...это детский сад, увы. Нет, я тоже чаще "меряю на глазок", чем отмеряю микрометром [и отрубаю топором], но это всё же осознавать надо. > Обращаясь и к вам, и к остальным читающим. Не слушайте ни меня, > ни господина с чиселками - поставьте rg на свою машину Перечитайте, пожалуйста, #12 и подскажите, где взять rust для e2k. Моя основная рабочая машина именно на этой архитектуре. PS: если "чиселки" не разобрали -- хотя бы отгрепав глазами(sic!) по real -- то главная из них там была 15 (та, что в последней строчке), как мне кажется. По сути это измерение скорости запуска, а для оценки самой молотилки стоило бы погонять на -F разной длины и регэксах разной заковыристости по массивам данных от единиц байт (как там) до хотя бы мегабайт. Если интересно -- ну так займитесь же, заодно можно теорию погрешностей подтянуть или вовсе открыть для себя :-)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	54. "Выпуск утилиты GNU grep 3.4"	–1 +/–
	Сообщение от Аноним (18), 03-Янв-20, 20:34
	С высоты птичьего полета, безо всякой теории погрешностей. У меня не SSD, как у господина с чиселками - у меня зашифрованный раздел на жестком диске, и на нем я наблюдаю значительную разницу. И чиселками я бросаться не буду, потому что числелки на каких-то непонятных данных, на чьей-то чужой машине со своей конфигурацией, в чем-то убеждают, мне кажется, только не слишком далеких людей. > где взять rust для e2k. Архитектура довольно молодая, почему она уже обязана поддерживаться llvm? Прочитал, что у вас есть двоичная трансляция из x86 - можете с ней попробовать. Я не то чтобы евангелист llvm - лучше бы у Rust был свой бекенд. Но пока как есть.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	60. "Выпуск утилиты GNU grep 3.4"	+/–
	Сообщение от Аноним (21), 03-Янв-20, 21:33
	>непонятных данных А чё, можете сами проверить. Вот вам данные http://ftp.freedb.org/pub/freedb/freedb-complete-20191203.ta... и вот вам текст, который нужно извлечь во всех файлах: '(\[.?\]+)' Теперь если скажете, какие ключи надо скормить rg, тобы тот отработал сопоставимо с grep -RPo (и желательно выдал те же данные в том же формате), я признаю, что раст имеет право на существование.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	58. "Выпуск утилиты GNU grep 3.4"	+/–
	Сообщение от Аноним (21), 03-Янв-20, 21:07
	Вот вам более реальное тестирование. Это всё, что нужно знать о хипстоподелках и восторженных отзывах в интернете. https://www.opennet.ru/openforum/vsluhforumID3/119373.html#57
	Ответить \| Правка \| К родителю #51 \| Наверх \| Cообщить модератору


	57. "Выпуск утилиты GNU grep 3.4"	–1 +/–
	Сообщение от Аноним (21), 03-Янв-20, 21:03
	> Угу, здорово. Я ведь тоже вам могу сейчас случайных чиселок набросать, но > заниматься этим я, конечно, не буду, потому что это детский сад. > Если бы вы действительно хотели выяснить правду, а не подтвердить для себя > собственное мнение, вы бы серьезно изучили вопрос, провели бы много разных > тестов и скорее всего сюда бы ничего не написали. Ну знаю, у меня не было мнения. Но я считаю, что должно быть сопоставимо с си, а не в 4 раза медленней (тем более, если речь идёт об использовании в скриптах, а не о разборе гигабайтов текста). Пытаюсь придумать тестирование с другим тестовым набором данных (где я возьму гигабайт текста?), но пока не получается и результаты выглядят ещё хуже для противников гну. Хорошо, реальный юзкейс. Грепнул 1.1гб текста/1100000 файлов (сущий пустяк, в принципе, во всяком случае для меня и моих данных) и чёт совсем грустно стало. В общем, прекращайте фейкомётить. rg: real 61m38.956s user 0m34.536s sys 1m1.371s grep: real 2m44.097s user 0m11.746s sys 0m24.306s Во время работы рг потреблял 200+ мб оперативки (уже несколько дико для применения в скриптах), греп всего 30мб. А если его тысячу раз в секунду вызывать? Ведь чем больше футпринт, тем больше сайд эффектов при использовании выплывает. Зачем он спавнит кучу тредов, кстати? Ведь всё равно значительно быстрее не будет, а на случайном доступе просадки только такие. Выглядит, как типичная хипстоподелка каких-то школьников. Не то, чтобы это было плохо само по себе, но вот то, как вы о ней отзываетесь... И это будет конкурировать с гну греп? Вы серьёзно? Посмотрите на цифры ещё раз: менее 3х минут и более 60...
	Ответить \| Правка \| К родителю #44 \| Наверх \| Cообщить модератору


	63. "Выпуск утилиты GNU grep 3.4"	–1 +/–
	Сообщение от Аноним (18), 03-Янв-20, 22:15
	Ни разу не удавалось подобного результата добиваться, у меня всегда rg работал лучше. Что ж, значит ripgrep еще не так хорош и ему есть над чем работать, все же GNU grep куда более зрелая тула. Попробую воспроизвести что-то подобное у себя. Пока не очень получилось.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	71. "Выпуск утилиты GNU grep 3.4"	+/–
	Сообщение от Аноним (18), 04-Янв-20, 00:20
	Честно говоря, не представляю, как вы такого добились и уже подумываю забрать свои слова назад. Скорее всего проблема в количестве файлов - на огромном числе файлов я еще не проверял. Я зарекался чиселки кидать, но ладно. Нашел рандомные логи http://www.almhuette-raith.at/apache-log/access.log (906M) > time rg '(\[.?\]+)' access.log \| wc -l 4595960 real 0m1.306s user 0m1.206s sys 0m0.577s > time grep -P '(\[.?\]+)' access.log \| wc -l 4595960 real 0m2.329s user 0m2.101s sys 0m0.949s Больше всего отличился ag: > time ag '(\[.?\]+)' access.log \| wc -l 4595960 real 0m22.608s user 0m22.472s sys 0m0.986s После я рандомным образом изменил паттерн. > time rg '(\[.?\]+).*test' test.log \| wc -l 6302 real 0m0.266s user 0m0.203s sys 0m0.072s Ни для grep, ни для ag я результата дождаться не смог. Не знаю, с чем это связано (скорее всего с этим: https://mariusschulz.com/blog/why-using-the-greedy-in-regula... - потому вдвойне забавно, что rg это спокойно прожевал), но сейчас нет возможности доводить эксперимент до конца. Может хватит обзывать "школьными хипстерскими поделками" все, что вам лично не нравится по идеологическим причинам? Потому что лично вы себя ведете как самый обыкновенный школьник-задира.
	Ответить \| Правка \| К родителю #57 \| Наверх \| Cообщить модератору


	77. "Выпуск утилиты GNU grep 3.4"	+/–
	Сообщение от анонн. (?), 04-Янв-20, 01:19
	> Я зарекался чиселки кидать, но ладно. Нашел рандомные логи http://www.almhuette-raith.at/apache-log/access.log > (906M) (В)брошу свои чиселки: >> time rg '(\[.?\]+)' access.log \| wc -l > 4595960 > real 0m1.306s > user 0m1.206s > sys 0m0.577s >> time grep -P '(\[.?\]+)' access.log \| wc -l > 4595960 > real 0m2.329s > user 0m2.101s > sys 0m0.949s с tmpfs, лучший результат 4 запусков % time rg -c '(\[.?\]+)' access.log 4596036 rg -c '(\[.?\]+)' access.log 1,46s user 0,17s system 99% cpu 1,632 tota % time rg -c -j1 '(\[.?\]+)' access.log 4596036 rg -c -j1 '(\[.?\]+)' access.log 1,46s user 0,15s system 99% cpu 1,607 total time /usr/local/bin/grep -cP '(\[.?\]+)' access.log 4596036 /usr/local/bin/grep -cP '(\[.?\]+)' access.log 3,53s user 0,28s system 99% cpu 3,813 total > Ни для grep, ни для ag я результата дождаться не смог. Не > знаю, с чем это связано (скорее всего с этим: https://mariusschulz.com/blog/why-using-the-greedy-in-regula... > - потому вдвойне забавно, что rg это спокойно прожевал), но сейчас > нет возможности доводить эксперимент до конца. Тут уже находили анти-паттерн для rg: seq 100000000 > fstfile time rg -ic 1 fstfile 47400465 rg -ic 1 fstfile 5,10s user 0,13s system 99% cpu 5,237 total time /usr/local/bin/grep -ic 1 fstfile 47400465 /usr/local/bin/grep -ic 1 fstfile 4,28s user 0,35s system 99% cpu 4,640 total time /usr/local/bin/grep -ic "^1" fstfile 11111113 /usr/local/bin/grep -ic "^1" fstfile 3,02s user 0,33s system 99% cpu 3,351 total time rg -ic "^1" fstfile 11111113 rg -ic "^1" fstfile 7,77s user 0,24s system 99% cpu 8,019 total Но это уж совсем синтетика - стоит добавить пару знаков и разница уходит: time rg -ic "^12" fstfile 11111 rg -ic "^12" fstfile 1,83s user 0,19s system 99% cpu 2,020 total time /usr/local/bin/grep -ic "^12" fstfile 11111 /usr/local/bin/grep -ic "^12" fstfile 2,69s user 0,32s system 99% cpu 3,017 total Удивительно правда, что у здешнего анонима _все_ оказалось антипаттерном, да еще и c разницей на порядки.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	79. "Выпуск утилиты GNU grep 3.4"	+/–
	Сообщение от Аноним (18), 04-Янв-20, 01:36
	> Удивительно правда, что у здешнего анонима _все_ оказалось антипаттерном, да еще и c разницей на порядки. Вот потому я и не хотел играть в эти идиотские чиселки. Всегда можно подобрать удобное окружение и подходящие данные, для которых чиселки какие надо получатся. Для такого инструмента как grep, в конечном счете все определяет только личная статистика использования на повседневных задачах. Моя такова, что на моих задачах и на моих машинах rg выигрывает. Но раз уж я влез в эту глупость, все-таки проверил grep и ag: > time grep -P '(\[.?\]+).test' test.log \| wc -l 6302 real 9m2.752s user 9m2.289s sys 0m0.080s > time ag '(\[.?\]+).test' test.log \| wc -l 6302 real 8m34.161s user 8m33.436s sys 0m0.100s
	Ответить \| Правка \| Наверх \| Cообщить модератору


	78. "Выпуск утилиты GNU grep 3.4"	+/–
	Сообщение от Аноним (21), 04-Янв-20, 01:34
	1 файл это не спортивно. Лично мне нравится руст, но не нравится результат где примитивная утилита сливает в 20 раз на типичном юзкейсе.
	Ответить \| Правка \| К родителю #71 \| Наверх \| Cообщить модератору


	73. "Выпуск утилиты GNU grep 3.4"	+2 +/–
	Сообщение от анонн. (?), 04-Янв-20, 00:37
	> Хорошо, реальный юзкейс. Грепнул 1.1гб текста/1100000 файлов (сущий пустяк, в принципе, > во всяком случае для меня и моих данных) и чёт совсем > грустно стало. В общем, прекращайте фейкомётить. Ну вот вам: find /usr/src -type f \|wc -l 83928 du -sh /usr/src 2,5G /usr/src результат третьего запуска греп (чтоб точно искать с кэша): grep --version grep (GNU grep) 3.3 Copyright (C) 2018 Free Software Foundation, Inc. time /usr/local/bin/grep -RPo '(\[.?\]+)' /usr/src \|wc -l 1093008 /usr/local/bin/grep -RPo '(\[.?\]+)' /usr/src 8,14s user 1,85s system 99% cpu 9,995 total wc -l 0,12s user 0,00s system 1% cpu 9,994 total time rg -uuuo '(\[.?\]+)' /usr/src \|wc -l 1093006 rg -uuuo '(\[.?\]+)' /usr/src 3,22s user 3,22s system 354% cpu 1,818 total wc -l 0,10s user 0,22s system 17% cpu 1,815 total в один тред % time rg -uuuo -j1 '(\[.?\]+)' /usr/src \|wc -l 1093006 rg -uuuo -j1 '(\[.?\]+)' /usr/src 2,02s user 1,70s system 99% cpu 3,728 total wc -l 0,09s user 0,02s system 2% cpu 3,726 total Потребление памяти: 18МБ RES. Похоже кто-то, не будем указывать пальцем на анонима, собрал дебаг-билд и бодро с ним сравнил релиз билд grep. Ну или точные опции запуска - в студию!
	Ответить \| Правка \| К родителю #57 \| Наверх \| Cообщить модератору


	74. "Выпуск утилиты GNU grep 3.4"	+/–
	Сообщение от анонн. (?), 04-Янв-20, 00:40
	В догонку: rg --version ripgrep 11.0.2
	Ответить \| Правка \| Наверх \| Cообщить модератору


	76. "Выпуск утилиты GNU grep 3.4"	+/–
	Сообщение от Аноним (21), 04-Янв-20, 01:13
	ok, grep ядра (без кэшей), 0.5 мб памяти в пике, 2.5 shared 2863 real 0m17.642s user 0m4.675s sys 0m1.727s rg (без кэшей, упал?), 1мб памяти в пике плюс 5.5 shared thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', src/libcore/option.rs:378:21 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace. 2862 real 0m18.099s user 0m0.976s sys 0m1.803s в 4 потока rg 2862 real 0m5.618s user 0m0.784s sys 0m1.573s Справедливости ради повторный запуск grep real 0m5.130s user 0m4.546s sys 0m0.539s повторный запуск rg thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', src/libcore/option.rs:378:21 stack backtrace: 0: <unknown> 1: <unknown> 2: <unknown> 3: <unknown> 4: <unknown> 5: <unknown> 6: <unknown> 7: <unknown> 8: <unknown> 9: <unknown> 10: <unknown> 11: <unknown> 12: <unknown> 13: <unknown> 14: <unknown> 15: <unknown> 16: <unknown> 17: __libc_start_main 18: <unknown> note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace. 2862 real 0m1.035s user 0m0.540s sys 0m0.459s rg в 4 потока 2862 real 0m0.721s user 0m0.559s sys 0m0.518s по-моему всё это множится на 0 фактом того, что данных мало и они синтетические в рамках данного "теста". Вон я же дал датасет приближенный к реальным данным, почему не используете его? http://ftp.freedb.org/pub/freedb/freedb-complete-20191203.ta... Ну и стоит всё же использовать hdd, на ssd вы много данных не разместите. >дебаг-билд нет
	Ответить \| Правка \| К родителю #73 \| Наверх \| Cообщить модератору


	80. "Выпуск утилиты GNU grep 3.4"	+/–
	Сообщение от анонн. (?), 04-Янв-20, 01:52
	> rg (без кэшей, упал?), 1мб памяти в пике плюс 5.5 shared Чего-чего, но падений я еще не видел. > Вон я же дал датасет приближенный к реальным данным, почему не используете > его? http://ftp.freedb.org/pub/freedb/freedb-complete-20191203.ta... Наверное, потому что не влезет в tmpfs, да и качаться будет минут 10? > Ну и стоит всё же использовать hdd, на ssd вы много данных не разместите. Это мне в ящике стола ковыряться, хард искать, подключать … да и какой смысл измерять скорость чтения с диска, в который все и упрется (если оно не поместится в кэше). >>дебаг-билд > нет Но билд, судя по паникам - кривоват.
	Ответить \| Правка \| Наверх \| Cообщить модератору