Pull to refresh

Comments 32

Коротко: не используйте RegEx там, где достаточно String.prototype.indexOf()

В любой ситуации, когда можно обойтись без регулярных выражений. Это же был просто пример.

UFO just landed and posted this here
\\!\\#\\%
так тут еще экранируется экранирование

Вот один из отличных on-line reg-exp редакторов: https://regex101.com/, в нем отлично реализована как подсветка групп, так и в целом cook-book имеется. + Поддерживаются различные популярные реализации.

А так же имеется счётчик сложности (шагов, необходимых движку на парсинг).

Круто, спасибо). Буду использовать.

Мило. Бегло пробежал по тексту и подумал, что у меня опять ГПУ ускорение в бразузере глючит.

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

Каждому инструменту должно быть свое применение. Если мне не изменяет память — HTML не является регулярным языком. Конечно, с использованием расширенных возможностей, вроде бэктрекинга, вы наверное сможете разобрать какое-то подмножество HTML. Но в общем случае, если взять любой движок и любой HTML — это невозможно.

Здесь возразить нечего, соглашусь.

В HTML возможна закрывающая треугольная скобка внутри значения атрибута. То есть простой вариант поиска тега уже разваливается. Ещё там возможны комментарии и вставки js и css (где могут быть любые расклады по скобкам и кавычкам). Вероятно, это всё можно запихнуть в регекс, но обезболить такой регекс уже не получится.

Да, согласен. Видимо, мы просто не сталкивались с такими проблемами во время работы, поэтому RegEx нам подходил.

Я запускал на NodeJS один миллион раз. Вероятно, здесь V8 постарался и оптимизировал алгоритм.

У вас результат никак не используется, компилятор вообще может выкинуть всё вычисление.

Возможно, но в одном случае выкидывает, а во втором - нет? Предлагаю просто оставить это как результат моего эксперимента.

Эвристики не всегда срабатывают. Вас во не смущает, что одна итерация проходит за 1.4 наносекунды? Это в лучшем случае 5 тактов процессора.

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

Зачем мучаться с регулярками (и дважды экранировать обычные символы), если можно писать нормальный код?

Не готов вступать в дискуссию, так как сам не ярый любитель регулярок.

Есть миф, что регулярные выражения более производительные, чем работа через встроенные методы классов вроде String

Если нужно найти одно вхождение - да, будет медленнее.
Когда задача найти несколько разных строк, или более сложных условий - всё становится гораздо лучше.
Это как использовать StringBuilder вместо конкатенации 2х строк.

И да, вы же не забыли что у регулярок конечные автоматы
под капотом?

Да, я согласен, что в сложных случаях нужно использовать регулярки. Об этом я написал в пункте "Без RegEx не обойтись".

А разве регекс не должен компилироваться? Я понимаю, если бы его создавали в цикле, но в цикле только использование, непонятно, почему в десятки раз медленнее, чем поиск по строке.

Потому что алгоритм идет по каждому символу в строке по порядку, применяя к нему все возможные вычисления. А работа со строкой будет оптимизирована. Я попытался найти алгоритм поиска по строке, но не получилось (возможно, кто-то может подсказать из читателей). Насколько я знаю, есть только некоторые требования к подобным алгоритмам, а как его реализовать - это решают разработчики JS движка.

Мемасик топ!
В целом согласен с выводом, да и сам придерживаюсь подобных практик при использовании регулярок.
Кому-нибудь будет полезно.

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

Согласен, при сложных кейсах реально без них не обойтись.

  • RegExp -- Regular Expressions -- правильно переводить -- "УПРАВЛЯЮЩИЕ Выражения".

  • RegExp -- это микропрограмма, которая компилируется в высокоскоростной конечный автомат, заточенный под обработку строк. Изначально предназначен на работу исключительно со строками из символов диапазона ASCII-7. Цель -- выполнять несколько операций поиска дополнительно используя ещё и математические выборки за один вызов.

  • в настоящее время в движке V8 (Chromium, Node), в редакторах SublimeText, VisualStudio Code и много где ещё используется расширенная реализация основанная на Си-шной библиотеке Boost, которую модифицируют под нужды приложений (того же V8, например), и в качестве расширений добавляют модификаторы якорей, поддержку Unicode/UTF8, дополнительные проверки контекста. Хотя, на мой взгляд, она сама хорошо оптимизирована и имеет арсенал богаче, чем изначальный ставший популярным вариант на Perl, который кое-где называют PCRE - Perl Compatible Regular Expressions.

На сегодняшний день, лично я рекомендую использовать одиночные операции со строками (IndexOf, например) исключительно для читаемости кода.

Но если важна производительность или краткость исходника (при минификации и/или оптимизации обработанный код получается компактнее, меньше внутренних переходов и вызовов), то РегЕксп предпочтительней даже для простейших операций.

Дополнительно это может дать единый формат ответа функции обработки, что крайне важно при конвеерной обработке, где данные меняются от шага к шагу (про микроконвеер самих РегЕкспов уже всё все поняли)

Если много операций со строками, то разница в размере бандла и скорости работы:

  • Вас приятно удивит на JavaScript и Go,

  • ничего не скажет на Python2, будет заметна на Python3,

  • и разочарует на чистом C.

Причина разочарования -- С компилируется в процессорный, а не промежуточный байт-код или собирается в бандл.

Дело в том, что реализация одиночных вызовов (о, чудо!) в современных реализациях ВСЕХ языков программирования использует тот же подход, который был в основе РегЕксп-ов

Ну, а чтобы легче понимать Регулярки, точнее их основу, не поленитесь, найдите документацию по JScript5 от Microsoft, которая шла в поставе Office"95, Office"97 и Office"2003, шла в комплекте с WScript, была в составе официальной поставки Windows XP и Windows Vista. Название файла JSCRIPT5.CHM

На мой взгляд -- лучшая документация по регуляркам. Книжка Фидла толщиной в 400 страниц курит в сторонке по сравнению с 3 страницами из доки от MS.

Всем успеха в понимании и изучении!

Only those users with full accounts are able to leave comments. Log in, please.