SS
По понятным причинам бенчмаркать серьёзно движки довольно бесполезно, все утверждения в целом ведутся про какие-то субъективные ощущения от использования. Но на своих данных протестить grep vs ripgrep очень просто:)
Size: a a a
2020 November 07
YS
И где сравнивали?)
Я как-то сходу нагуглил. А Вы ничего не нашли?
> По факту у нас и есть только 2-3 движка достаточно быстрых
По какому "факту"? Опять-таки, как вообще можно всерьёз сравнивать PCRE и fgrep (имеется в виду что-то очень быстрое... но почти ничего не умеющее, если что)?
> По факту у нас и есть только 2-3 движка достаточно быстрых
По какому "факту"? Опять-таки, как вообще можно всерьёз сравнивать PCRE и fgrep (имеется в виду что-то очень быстрое... но почти ничего не умеющее, если что)?
SS
Yaroslav Schekin
Я как-то сходу нагуглил. А Вы ничего не нашли?
> По факту у нас и есть только 2-3 движка достаточно быстрых
По какому "факту"? Опять-таки, как вообще можно всерьёз сравнивать PCRE и fgrep (имеется в виду что-то очень быстрое... но почти ничего не умеющее, если что)?
> По факту у нас и есть только 2-3 движка достаточно быстрых
По какому "факту"? Опять-таки, как вообще можно всерьёз сравнивать PCRE и fgrep (имеется в виду что-то очень быстрое... но почти ничего не умеющее, если что)?
Ну накидайте ссылок, интересно ж
же
Про три движка - все субъективно, но сравнивать PCRE vs fgrep, очевидно, можно, потому что выбор движка на этапе компиляции запроса - реальная и широко распространенная практика
же
Про три движка - все субъективно, но сравнивать PCRE vs fgrep, очевидно, можно, потому что выбор движка на этапе компиляции запроса - реальная и широко распространенная практика
S
Вопрос, сопряжённый с vim.
Никто в vi mode в zsh не делал вывод всех режимов в PROMPT?
Есть zle-keymap-select, но там нет значения KEYMAP, которое бы отличало VISUAL от NORMAL.
Можно лишь INSERT и NORMAL разграничивать.
Есть отдельные плагины, но они какие-то жирные, и, возможно, есть способ это реализовать проще?
https://github.com/b4b4r07/zsh-vimode-visual
Никто в vi mode в zsh не делал вывод всех режимов в PROMPT?
Есть zle-keymap-select, но там нет значения KEYMAP, которое бы отличало VISUAL от NORMAL.
Можно лишь INSERT и NORMAL разграничивать.
Есть отдельные плагины, но они какие-то жирные, и, возможно, есть способ это реализовать проще?
https://github.com/b4b4r07/zsh-vimode-visual
SS
Там в интернете много статеек вида "рипгреп медленный, я написал за вечер лучше на питоне, пруфов не будет", но это все из серии псевдонауки
YS
Ну накидайте ссылок, интересно ж
же
Про три движка - все субъективно, но сравнивать PCRE vs fgrep, очевидно, можно, потому что выбор движка на этапе компиляции запроса - реальная и широко распространенная практика
же
Про три движка - все субъективно, но сравнивать PCRE vs fgrep, очевидно, можно, потому что выбор движка на этапе компиляции запроса - реальная и широко распространенная практика
> Там в интернете много статеек вида "рипгреп медленный, я написал за вечер лучше на питоне, пруфов не будет"
В плане "накидать ссылок" попадается в основном такое, не спорю. ;)
Но сам движок стоит сравнивать с технологически аналогичными — RE2, движком PostgreSQL / Tcl (Spencer's) и т.п.
> но сравнивать PCRE vs fgrep, очевидно, можно
IMNSHO — нет, "в общем" их сравнивать нельзя. Или уж сравнивать нужно честно, т.е. любой тест, который fgrep "не умеет" (т.е. почти все), записывать как "бесконечно долго". Результат сравнения немного предсказуем. ;)
Аналогично и при сравнении движка rg с чем-то, у чего больше возможностей.
Потому что "Rust's regex engine uses finite automata, SIMD and aggressive literal optimizations..." сильно подрывает выразительность, конечно (другой вопрос, что такие RE могут быть и так достаточно хороши, да).
Но если нет — см. https://news.ycombinator.com/item?id=12567328 :
"If you try out ripgrep, don't get your hopes up. Unless you're searching some really big codebases, you won't notice the speed difference. What you will notice, however, are the feature differences."
> потому что выбор движка на этапе компиляции запроса
Это другое дело, конечно. Раньше (да в том же 2016) такого было немного, насколько я помню.
А что ещё так делает в наше время?
В плане "накидать ссылок" попадается в основном такое, не спорю. ;)
Но сам движок стоит сравнивать с технологически аналогичными — RE2, движком PostgreSQL / Tcl (Spencer's) и т.п.
> но сравнивать PCRE vs fgrep, очевидно, можно
IMNSHO — нет, "в общем" их сравнивать нельзя. Или уж сравнивать нужно честно, т.е. любой тест, который fgrep "не умеет" (т.е. почти все), записывать как "бесконечно долго". Результат сравнения немного предсказуем. ;)
Аналогично и при сравнении движка rg с чем-то, у чего больше возможностей.
Потому что "Rust's regex engine uses finite automata, SIMD and aggressive literal optimizations..." сильно подрывает выразительность, конечно (другой вопрос, что такие RE могут быть и так достаточно хороши, да).
Но если нет — см. https://news.ycombinator.com/item?id=12567328 :
"If you try out ripgrep, don't get your hopes up. Unless you're searching some really big codebases, you won't notice the speed difference. What you will notice, however, are the feature differences."
> потому что выбор движка на этапе компиляции запроса
Это другое дело, конечно. Раньше (да в том же 2016) такого было немного, насколько я помню.
А что ещё так делает в наше время?
VL
Пользуюсь рипгрером и фзф в виме
Работает быстро, есть не просит
Работает быстро, есть не просит
VL
Спасибо за унимание
D
First name Last name
а на аве генту..
У меня же не один комп, есть компы с другими пользователями, не всеми я пользуюсь. Ну это так уточнение для тех, кому не очевидно, что люди иногда не одни живут
SS
Yaroslav Schekin
> Там в интернете много статеек вида "рипгреп медленный, я написал за вечер лучше на питоне, пруфов не будет"
В плане "накидать ссылок" попадается в основном такое, не спорю. ;)
Но сам движок стоит сравнивать с технологически аналогичными — RE2, движком PostgreSQL / Tcl (Spencer's) и т.п.
> но сравнивать PCRE vs fgrep, очевидно, можно
IMNSHO — нет, "в общем" их сравнивать нельзя. Или уж сравнивать нужно честно, т.е. любой тест, который fgrep "не умеет" (т.е. почти все), записывать как "бесконечно долго". Результат сравнения немного предсказуем. ;)
Аналогично и при сравнении движка rg с чем-то, у чего больше возможностей.
Потому что "Rust's regex engine uses finite automata, SIMD and aggressive literal optimizations..." сильно подрывает выразительность, конечно (другой вопрос, что такие RE могут быть и так достаточно хороши, да).
Но если нет — см. https://news.ycombinator.com/item?id=12567328 :
"If you try out ripgrep, don't get your hopes up. Unless you're searching some really big codebases, you won't notice the speed difference. What you will notice, however, are the feature differences."
> потому что выбор движка на этапе компиляции запроса
Это другое дело, конечно. Раньше (да в том же 2016) такого было немного, насколько я помню.
А что ещё так делает в наше время?
В плане "накидать ссылок" попадается в основном такое, не спорю. ;)
Но сам движок стоит сравнивать с технологически аналогичными — RE2, движком PostgreSQL / Tcl (Spencer's) и т.п.
> но сравнивать PCRE vs fgrep, очевидно, можно
IMNSHO — нет, "в общем" их сравнивать нельзя. Или уж сравнивать нужно честно, т.е. любой тест, который fgrep "не умеет" (т.е. почти все), записывать как "бесконечно долго". Результат сравнения немного предсказуем. ;)
Аналогично и при сравнении движка rg с чем-то, у чего больше возможностей.
Потому что "Rust's regex engine uses finite automata, SIMD and aggressive literal optimizations..." сильно подрывает выразительность, конечно (другой вопрос, что такие RE могут быть и так достаточно хороши, да).
Но если нет — см. https://news.ycombinator.com/item?id=12567328 :
"If you try out ripgrep, don't get your hopes up. Unless you're searching some really big codebases, you won't notice the speed difference. What you will notice, however, are the feature differences."
> потому что выбор движка на этапе компиляции запроса
Это другое дело, конечно. Раньше (да в том же 2016) такого было немного, насколько я помню.
А что ещё так делает в наше время?
RE2 — не вершина развития, он внутри довольно плох, кстати, и зачастую (опять же, субъективно; есть biased бенчмарки от Intel https://01.org/hyperscan/blogs/jpviiret/2017/regex-set-scanning-hyperscan-and-re2set) проигрывает Hyperscan. Да и rust regex (https://github.com/rust-lang/regex/blob/master/bench/log/05/re2-vs-rust; сравнение, как обычно, biased, но почти никто другой не удосужился побенчмаркать нормально свои либы). Вот ещё (https://meetingcpp.com/mcpp/slides/2018/slides.pdf#83) независимый бенчмарк, из него интересно на PCRE vs RE2 смотреть; Hyperscan и Rust Regex не измеряли, но в рантайме я бы ожидал ещё меньших значений.
Бенчмарки с Tcl не видел, интересно поискать, это правда, но что-то я удивлюсь, если там будет что-то выдающееся по производительности.
Сравнивать PCRE и тот же fgrep можно на запросах, на которых работает fgrep, если стоит цель выяснить более эффективный, что бы это не значило, движок: как было сказано выше, наиболее эффективный в таком случае вариант — использовать fgrep на подмножестве запросов, про которые понятно, что они будут выполняться дольше (классификатор — это отдельная и очень широкая тема, в целом сейчас работает подход "если не компилируется, то фоллбек на PCRE).
Да, ripgrep с 2016 года сильно поменялся, это же почти первые версии были. С тех пор он крайне активно разрабатывается и даже замахнулся на значительно более сложную область — поиск по предпосчитанному индексу (где, собственно, я и изучал вопрос).
Из использующих подобный подход с выбором движка по самому запросу я помню только ripgrep и Intel Chimera, про которую уже упоминал; это Hyperscan с фоллбеком на PCRE.
UPD: Добавил ссылок пропущенных
Бенчмарки с Tcl не видел, интересно поискать, это правда, но что-то я удивлюсь, если там будет что-то выдающееся по производительности.
Сравнивать PCRE и тот же fgrep можно на запросах, на которых работает fgrep, если стоит цель выяснить более эффективный, что бы это не значило, движок: как было сказано выше, наиболее эффективный в таком случае вариант — использовать fgrep на подмножестве запросов, про которые понятно, что они будут выполняться дольше (классификатор — это отдельная и очень широкая тема, в целом сейчас работает подход "если не компилируется, то фоллбек на PCRE).
Да, ripgrep с 2016 года сильно поменялся, это же почти первые версии были. С тех пор он крайне активно разрабатывается и даже замахнулся на значительно более сложную область — поиск по предпосчитанному индексу (где, собственно, я и изучал вопрос).
Из использующих подобный подход с выбором движка по самому запросу я помню только ripgrep и Intel Chimera, про которую уже упоминал; это Hyperscan с фоллбеком на PCRE.
UPD: Добавил ссылок пропущенных
YS
RE2 — не вершина развития, он внутри довольно плох, кстати, и зачастую (опять же, субъективно; есть biased бенчмарки от Intel https://01.org/hyperscan/blogs/jpviiret/2017/regex-set-scanning-hyperscan-and-re2set) проигрывает Hyperscan. Да и rust regex (https://github.com/rust-lang/regex/blob/master/bench/log/05/re2-vs-rust; сравнение, как обычно, biased, но почти никто другой не удосужился побенчмаркать нормально свои либы). Вот ещё (https://meetingcpp.com/mcpp/slides/2018/slides.pdf#83) независимый бенчмарк, из него интересно на PCRE vs RE2 смотреть; Hyperscan и Rust Regex не измеряли, но в рантайме я бы ожидал ещё меньших значений.
Бенчмарки с Tcl не видел, интересно поискать, это правда, но что-то я удивлюсь, если там будет что-то выдающееся по производительности.
Сравнивать PCRE и тот же fgrep можно на запросах, на которых работает fgrep, если стоит цель выяснить более эффективный, что бы это не значило, движок: как было сказано выше, наиболее эффективный в таком случае вариант — использовать fgrep на подмножестве запросов, про которые понятно, что они будут выполняться дольше (классификатор — это отдельная и очень широкая тема, в целом сейчас работает подход "если не компилируется, то фоллбек на PCRE).
Да, ripgrep с 2016 года сильно поменялся, это же почти первые версии были. С тех пор он крайне активно разрабатывается и даже замахнулся на значительно более сложную область — поиск по предпосчитанному индексу (где, собственно, я и изучал вопрос).
Из использующих подобный подход с выбором движка по самому запросу я помню только ripgrep и Intel Chimera, про которую уже упоминал; это Hyperscan с фоллбеком на PCRE.
UPD: Добавил ссылок пропущенных
Бенчмарки с Tcl не видел, интересно поискать, это правда, но что-то я удивлюсь, если там будет что-то выдающееся по производительности.
Сравнивать PCRE и тот же fgrep можно на запросах, на которых работает fgrep, если стоит цель выяснить более эффективный, что бы это не значило, движок: как было сказано выше, наиболее эффективный в таком случае вариант — использовать fgrep на подмножестве запросов, про которые понятно, что они будут выполняться дольше (классификатор — это отдельная и очень широкая тема, в целом сейчас работает подход "если не компилируется, то фоллбек на PCRE).
Да, ripgrep с 2016 года сильно поменялся, это же почти первые версии были. С тех пор он крайне активно разрабатывается и даже замахнулся на значительно более сложную область — поиск по предпосчитанному индексу (где, собственно, я и изучал вопрос).
Из использующих подобный подход с выбором движка по самому запросу я помню только ripgrep и Intel Chimera, про которую уже упоминал; это Hyperscan с фоллбеком на PCRE.
UPD: Добавил ссылок пропущенных
> RE2 — не вершина развития, он внутри довольно плох, кстати
Конечно, не вершина — это "возврат к основам", скорее (т.е. удивительно именно то, что он вообще настолько хорош на современном уровне). Что намекает на то, что последние [почти] 60 лет движки шли куда-то не совсем туда. ;)
Я имел в виду именно используемые алгоритмы.
> сравнение, как обычно, biased,
То-то и оно. ;(
> почти никто другой не удосужился побенчмаркать нормально свои либы
Потому что нафиг надо и так good enough (а если нет, то и ладно — есть задачи поважнее). ;)
Т.е. в тех местах, куда они встроены, они обычно не представляют и 0.001% функционала языка (или продукта).
> из него интересно на PCRE vs RE2 смотреть
Это я почитаю, спасибо!
>Бенчмарки с Tcl не видел, интересно поискать, это правда, но что-то я удивлюсь
А вот: https://github.com/rust-lang/regex/blob/master/bench/log/05/tcl-vs-rust — и (к вопросу biased) я уже удивился — по-моему, автор не смог нормально "завести" (адаптировать / скомпилировать) этот движок или взял его не оттуда (во-первых, фактический upstream сейчас в PostgreSQL; во-вторых, в Tcl он работает только с utf-16, поэтому использование его на файлах "как есть" — автоматический performance hit как минимум в 2-3 раза).
> выяснить более эффективный, что бы это не значило
Ну это как-то несерьёзно, правда. ;)
> классификатор — это отдельная и очень широкая тема
Казалось бы, почему не просто "если это не умеет первый, используй второй" (как Вы и написали)?
> С тех пор он крайне активно разрабатывается и даже замахнулся на значительно более сложную область
Да, я заметил... но что это даёт на практике — другой вопрос. А n-грамные индексы — старая тема, на самом деле, просто в grep-ах до неё пока не очень-то дошли.
> Из использующих подобный подход с выбором движка по самому запросу я помню только ripgrep и Intel Chimera
Вот то-то и оно (Tcl всегда внутри таким был, но это исключение)... да и в vim-е нынче тоже два движка. :)
Конечно, не вершина — это "возврат к основам", скорее (т.е. удивительно именно то, что он вообще настолько хорош на современном уровне). Что намекает на то, что последние [почти] 60 лет движки шли куда-то не совсем туда. ;)
Я имел в виду именно используемые алгоритмы.
> сравнение, как обычно, biased,
То-то и оно. ;(
> почти никто другой не удосужился побенчмаркать нормально свои либы
Потому что нафиг надо и так good enough (а если нет, то и ладно — есть задачи поважнее). ;)
Т.е. в тех местах, куда они встроены, они обычно не представляют и 0.001% функционала языка (или продукта).
> из него интересно на PCRE vs RE2 смотреть
Это я почитаю, спасибо!
>Бенчмарки с Tcl не видел, интересно поискать, это правда, но что-то я удивлюсь
А вот: https://github.com/rust-lang/regex/blob/master/bench/log/05/tcl-vs-rust — и (к вопросу biased) я уже удивился — по-моему, автор не смог нормально "завести" (адаптировать / скомпилировать) этот движок или взял его не оттуда (во-первых, фактический upstream сейчас в PostgreSQL; во-вторых, в Tcl он работает только с utf-16, поэтому использование его на файлах "как есть" — автоматический performance hit как минимум в 2-3 раза).
> выяснить более эффективный, что бы это не значило
Ну это как-то несерьёзно, правда. ;)
> классификатор — это отдельная и очень широкая тема
Казалось бы, почему не просто "если это не умеет первый, используй второй" (как Вы и написали)?
> С тех пор он крайне активно разрабатывается и даже замахнулся на значительно более сложную область
Да, я заметил... но что это даёт на практике — другой вопрос. А n-грамные индексы — старая тема, на самом деле, просто в grep-ах до неё пока не очень-то дошли.
> Из использующих подобный подход с выбором движка по самому запросу я помню только ripgrep и Intel Chimera
Вот то-то и оно (Tcl всегда внутри таким был, но это исключение)... да и в vim-е нынче тоже два движка. :)
D
Горячие клавиши в шелле / Хабр
https://habr.com/ru/post/99843/
https://habr.com/ru/post/99843/
Ещё можно oh-my-zsh переводить в vi-mode и у командной строки появится обычный режим как в виме с теми же клавишами управления