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 ()
Последнее исправление: Dendy (всего исправлений: 2)

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

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

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

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

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

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

d ★★★★
()

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

arcanis ★★★★
()

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

Citius, Altius, Fortius!

sT331h0rs3 ★★★★★
()

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

v9lij ★★★★★
()

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

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

KennyMinigun ★★★★★
()

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

true_admin ★★★★★
()

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

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

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

anonymous
()

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

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

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

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

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

anonymous
()

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

lucentcode ★★★★★
()

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

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

next_time ★★★★★
()

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

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

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

d_Artagnan ★★
()

всегда радуют новости про grep

Marlboro
()

Если делать сразу 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
()

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

v9lij ★★★★★
()

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

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

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