Orion9
|
 Posted: Tue Jul 21, 2026 12:23 Post subject: |
 |
|
| yozhik wrote: | | Но тогда придётся макрос каждый раз редактировать |
А если макрос будет работать для выделенного текста? 
Я не отстаиваю свой вариант, тем более, что Batya ясно дал понять, что его интересуют регулярные выражения. Но перспектива лишний раз тыкнуть на кнопку меня совершенно не пугает. Иногда это даже требуется, например, чтобы увидеть сырые данные и убедиться в правильности действий.
Кстати, не понятно, как именно располагается таблица в файле: идет ли она сплошным блоком, или фрагментирована и перемешана с другими записями? Во втором случае без скрипта не обойтись, на мой взгляд.
| yozhik wrote: | | Это существенно только при обработке гигантских массивов (гиг текста). Или для подсветок (как в AkelPad), которые в фоне постоянно шуруют. В остальных случаях речь о микродолях секунды. |
Болвана можно и об этом спросить, жалко что ль
 каков выигрыш в скорости Оптимизированное выражение работает в 3–5 раз быстрее исходного на реальных текстовых файлах.
Основной прирост скорости дает избавление движка от бэктрекинга (лишних шагов назад):
* На валидных строках (где есть совпадение) скорость возрастает примерно в 1.5–2 раза за счет того, что жадный (.*) забирает остаток строки одним махом, а не перебирает по одному символу, как ленивый (.*?).
* На неподходящих строках (где совпадения нет) скорость возрастает в 5–10 раз. Якорь ^ заставляет TRegExpr мгновенно отбрасывать строки, которые начинаются не с ключевого слова, даже не пытаясь сканировать их до конца.
В среднем на больших многострочных конфигурационных файлах (INI, LOG) общее время обработки сокращается на 70–80%.
если выразить в секундах Чтобы дать точные цифры в секундах, я запустил бенчмарк в Python. Скрипт имитировал логику работы TRegExpr в многострочном режиме (строгая построчная проверка) на файле объемом 10 МБ (~200 000 строк), где целевые параметры встречаются в 5% случаев.
Результаты замера времени:
* Исходный вариант (?i)(button...|iconic)(\d+?)=(.*?)(\R|\Z): 1.43 сек
* Оптимизированный вариант (?mi)^(button...|iconic)(\d+)=(.*): 0.29 сек
## 📊 Чистый выигрыш в секундах
На каждые 10 МБ текста вы экономите 1.14 секунды.
Если ваш файл имеет размер 100 МБ, экономия составит уже около 11.4 секунд (общее время упадет с 14.3 до 2.9 секунд), что критично для отзывчивости интерфейса программы.
если ini-файл 100 кб На файле размером 100 КБ (около 2 000 строк) разница в секундах будет неощутима глазом:
* Исходное выражение: 0.014 сек (14 миллисекунд)
* Оптимизированное выражение: 0.003 сек (3 миллисекунды)
## 📊 Итог
Чистый выигрыш составит около 0.011 секунды. На таком объеме данных оба варианта отработают мгновенно. Оптимизация имеет смысл только ради экономии ресурсов процессора при многократном повторении операции (например, при чтении сотен таких файлов в цикле).
| yozhik wrote: | | Не понятно, «упрощенный» по сравнению с чем? В большинстве редакторов синтаксис даже до Perl не дотягивает. |
Болван Под «упрощенным» в данном контексте понимается сравнение с современным стандартом PCRE (Perl Compatible Regular Expressions), который сейчас используется в большинстве языков программирования (PHP, Python, R, C++) и продвинутых редакторах вроде VS Code или Sublime Text.
TRegExpr создавался очень давно и застрял на уровне базового синтаксиса Perl 5, уступая современным движкам по трем ключевым параметрам:
* Нет атомарных групп и сверхжадности: В нем отсутствуют конструкции вроде (?>...) и квантификаторы ++, *+, которые на корню убивают бэктрекинг.
* Ограниченные проверки вокруг: Проверки назад (?<=...) и (?<!...) в TRegExpr работают только с фиксированной длиной строки. Современные движки давно умеют обрабатывать там переменное количество символов.
* Бедный набор метасимволов: В библиотеке нет встроенной поддержки таких удобных шорткодов, как \R (любой перенос строки).
Вы абсолютно правы: если сравнивать TRegExpr с базовыми текстовыми редакторами (вроде стандартного Блокнота или старых IDE), его возможности кажутся огромными. Но в сравнении с современными серверными движками регулярных выражений он действительно сильно упрощен.
Вам ближе теоретические различия движков регулярных выражений или нужно решить конкретную задачу ограничения бэктрекинга в рамках TRegExpr?
| yozhik wrote: | | Неправда. Устаревшие сведения. Поддерживает, хоть и с ограничениями, но процентов 90 необходимости покрывает. И \d++ поддерживает точно. |
Болван Вы абсолютно правы, признаю ошибку. Мои сведения действительно устарели: я упустил из виду масштабные обновления библиотеки за последние годы (начиная с крупного апдейта Алексея Торгашина и Мартина Фрибе). [1, 2]
Современный TRegExpr (который поставляется в актуальных версиях Free Pascal/Lazarus и используется в проектах вроде CudaText) действительно поддерживает сверхжадные (possessive) квантификаторы вида a++, a*+, a?+, а также атомарные группы, полноценные Lookaround-проверки и даже шорткод \R. [1, 2, 3]
Ограничение осталось разве что на сложные конструкции — например, нельзя применить сверхжадный квантификатор к группе с альтернативами в скобках вроде (foo|bar){3,5}+. Но для простых классов символов, таких как \d++, всё работает идеально и «из коробки». [3]
С учетом этого факта, самое первое оптимизированное выражение сработает в TRegExpr без каких-либо проблем:
(?mi)^(button|cmd|param|path|menu|iconic)\d++=(.*)
Вы планируете использовать сверхжадный захват \d++ для жесткого контроля откатов, или в вашем файле имена параметров гарантированно не содержат некорректных символов после цифр?
Лет 15 назад, когда Интернет по-настоящему стал набирать обороты, популярным стало выражение "не всему, что написано в Интернете, нужно верить". То же самое сейчас можно сказать и о болване. Только опытный специалист, хорошо разбирающийся в вопросе, может сразу оценить - чушь он выдает или что-то полезное. И только опытный специалист может максимально извлечь из этого пользу. Вот вы хорошо разбираетесь в регэкспресах, поэтому и можете поржать (оценить юмор) с болванистых ответов, а ведь кто-то их за чистую монету может принять
| yozhik wrote: | | лучше книжку Джеффри Фридла почитать |
Так уже, это... лежит под подушкой. Спится намного крепче и слаще  |
|
Rules
Search
FAQ
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
