LINUX.ORG.RU

GNU Grep 2.19: быстрее от 10 до 200 раз

 


0

1

Cегодня вышла новая версия программы GNU Grep 2.19. Джим Мейеринг (Jim Meyering) сообщает, что за 13 недель, прошедших со времени выхода прошлой версии, 4 разработчика сделали 152 коммита. Особое спасибо Норихиро Танака (Norihiro Tanaka) и Паулю Эггерту (Paul Eggert).

Улучшения

  • Значительно улучшена производительность, в типичных случаях на 10% и в некоторых случаях в 200 раз. Однако, производительность grep -P (то есть, при работе с регулярными выражениями с стиле Perl) в юникодных локалях стала только хуже. Это связано с исправлениями ошибок, которые могли приводить к падениям (см. ниже).

Исправление ошибок

  • grep больше не ошибается при работе с паттернами вида [a-[.z.]] ([.z.] обозначает collating symbol) Например, раньше в испаноамериканской локали grep работал неверно, а теперь работает правильно:
    echo b | LC_ALL=es_US.UTF-8 grep '[a-[.ch.]]'
    echo $ echo b | LC_ALL=es_US.UTF-8 ../src/grep '[a-[.ch.]]'
    b
    
    Также исправлена ошибка, когда неправильно обрабатывались регулярные выражения типа [^a], где a — collating symbol.
  • grep больше не ошибается с пустыми регулярными выражениями, когда они присутствуют в списке паттернов. Если в списке паттернов присутствует пустая строка, то должны находиться все исходные строки. Например, в 2.18:
    $ pat='hello
    '
    $ echo world | grep -e "$pat"
    world
    $pat='\(\)\1hello
    '
    # ошибка!
    $ echo world | grep -e "$pat"
    $
    
    (эта ошибка появилась в версии 2.5);
  • grep -C NUM педантично печатает разделитель, когда NUM равно 0, аналогично для -A и -B (ошибка присутствовала изначально);
  • grep, grep -F, grep -E теперь обрабатывают ошибки в кодировке паттернов таким же образом, как их обрабатывает движок обработки регулярных выражений GNU, учитывая, может ли ошибка находить части многобайтовых символов в данных (ошибка присутствовала изначально).
  • grep -w теперь правильно работает в многобайтовых локалях. То же касается паттернов '\<', '\>', '\b', '\B':
    # grep 2.18
    $ echo 'Привет, Мир' | grep '\<М'
    $
    # grep 2.19
    $ echo 'Привет, Мир' | grep '\<М'
    Привет, Мир
    $
    
    (ошибка присутствовала изначально);
  • grep -P теперь сообщает об ошибке и выходит, когда на вход поступают некорректные данные в кодировке UTF-8. Раньше программа могла упасть или зациклиться (ошибка появилась в grep-2.16);
  • grep -Pw теперь работает аналогично grep -w, искомая строка должна быть окружена символами, которые не могут быть частью какого-либо слова. Ранее, например, echo a@@a| grep -Pw @@ находила строку, а cho a@@a| grep -w @@ — нет. Теперь работают одинаково и строку не находят.
  • grep -i теперь правильно обрабатывает паттеры, содержащие символы в верхнем регистре. Например, в локали, содержащей символ 'Lj' (U+01C8 LATIN CAPITAL LETTER L WITH SMALL LETTER J), 'grep -i Lj' теперь находит и строку 'LJ' (U+01C7 LATIN CAPITAL LETTER LJ), и lj' (U+01C9 LATIN SMALL LETTER LJ).

>>> Подробности

★★★★

Проверено: Shaman007 ()

ошибок, которые могли приводить к падениям

РЕШЕТО!

Igron ★★★★★ ()

быстрее от 10 до 200 раз

в типичных случаях на 10% и в некоторых случаях в 200 раз.

Автор, определись, на 10% или в 10 раз.

anonymous ()
Ответ на: комментарий от anonymous

Автор, определись, на 10% или в 10 раз.

В десять раз — это слишком сложно быстро для пользователя.

d ★★★ ()

Вроде и в прошлый раз что то там говорили по ускорение=)

arcanis ★★★ ()

быстрее от 10 до 200 раз

Citius, Altius, Fortius!

sT331h0rs3 ★★★★★ ()

В заголовке написано, что «от 10 раз», а в статье всего лишь про «на 10%». Нестыковка.

v9lij ★★★★ ()

Юзерам systemd grep не нужен!

Shadow ★★★★★ ()

Однако, производительность grep -P в юникодных локалях стала только хуже. Это связано с исправлениями ошибок, которые могли приводить к падениям.

Почему бы им просто не заюзать libperl?

KennyMinigun ★★★★★ ()
Ответ на: комментарий от KennyMinigun

Интересная мысль, кто быстрее грепает - perl или grep...

Shadow ★★★★★ ()

сколько же говна из-за этого юникода.

Bad_ptr ★★★ ()

Не думал что его есть куда ускорять. Я думал он даже jit использует. Оказалось что пока нет.

true_admin ★★★★★ ()

Наконец-то замарковьредисили, блямбдии шевелятся?! ДГЕР жеж... xD

Woofywoof ()
Последнее исправление: Woofywoof (всего исправлений: 1)
Ответ на: комментарий от Shadow

В смысле grep vs что-то вроде perl -ne 'print if /../' ? Скорее всего grep, там вроде обычно DFA, а NFA в отдельных случаях: гнутые расширения позволяют комбинировать backreferences с |, может еще случаи есть. Обычные ERE в общем случае точно должны быть быстрее.

anonymous ()

Почему всё grep да grep? А пошто cat никто не ускоряет?

greenman ★★★★★ ()

Юзал ack сначала, да тот быстрее. Потом узнал про ag (silverseacher) тот вообще рвёт на клочки - часто юзаю из вима. Ускорение за счёт многопоточности и вроде как своя функция readdir которая ещё на стадии чтения фильтрует.

anonymous ()
Ответ на: комментарий от Shadow

Да, у них ничего не грепается дабы просто загрузить ос.

anonymous ()
Ответ на: комментарий от Bad_ptr

Сколько же юникода из-за этого говна.

anonymous ()

Хорошая новость. grep юзаю постоянно, и иногда на довольно больших файлах. Так-что улучшение производительности, как и фиксы багов, не могут не радовать.

lucentcode ★★★★★ ()

Однако, производительность grep -P (то есть, при работе с регулярными выражениями с стиле Perl) в юникодных локалях стала только хуже. Это связано с исправлениями ошибок, которые могли приводить к падениям (см. ниже).

а нет ли специальной опции, котороя возвращала бы старое поведение, с багами?

next_time ★★★ ()

Разработчики grep переняли маркетинговые ходы Mozilla Foundation с анонсами по увеличение производительности JS в 20 раз с каждым релизом? :)

soko1 ★★★★★ ()

www.linux.org.ru/news/gnu/10199899

GNU Grep 2.17: десятикратный рост производительности


скоро будет предугадывать через libastral, чтоб еще быстрее было

r0ck3r ★★★★★ ()
Ответ на: комментарий от anonymous

Очевилно, ошибка в слове «раз». Должно быть : «порядков»

d_Artagnan ★★ ()

Если делать сразу return 0;, то еще в сотню раз быстрее будет.

cipher ★★★★★ ()
Ответ на: комментарий от yoghurt

этот такой сервис уже занимается регулированием яркости монитора, придумайте что-то по-оригинальнее

anonymous ()

быстрее от 10 до 200 раз

Хорошо! Интересно какой алгоритм там применяется для -ir.

splinter ★★★★★ ()

Значительно улучшена производительность, в типичных случаях на 10% и в некоторых случаях в 200 раз

GNU Grep 2.19: быстрее от 10 до 200 раз

В заголовке 4.2?

theNamelessOne ★★★★★ ()

Не нужно. Silversearcher ему уже не догнать.

anonymous ()
Ответ на: комментарий от d


В десять раз — это слишком сложно быстро для пользователя.

в конце концов, нужно уважать пользователей линукса

kto_tama ★★★★★ ()
Ответ на: комментарий от v9lij

«от 10 раз», а в статье всего лишь про «на 10%». Нестыковка.

это специальные гнутые проценты

anonymous ()

поделие неосиляторов perl -ne

fijiol ()
Ответ на: комментарий от eternal_sorrow

libpcre

libpcre по сути дублирует функциональность из libperl.

KennyMinigun ★★★★★ ()

аффтар, ты вообще читаешь комментарии? поправь свои уже проценты..шаману тоже пофиг, ему лишь бы кнопку нажать..

v9lij ★★★★ ()

GNU Grep 2.19: быстрее от 10 до 200 раз

Так теперь всё меньше и меньше стимулов учить си.

Umberto ★☆ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.