Comments 15
А цели и выводы исследования какие?
Спасибо. Интересно, но сложновато, перечитаю некоторое время спустя. Про регулярные особенно интересно.
Кстати, все ли утверждения в регулярных выражениях работают для preg_replace? Или есть ограничения?
Кстати, все ли утверждения в регулярных выражениях работают для preg_replace? Или есть ограничения?
На здоровье! Задавайте вопросы. Если их наберется достаточное количество — будет стимул для следующей статьи
Да, для шаблона preg_replace справедливо всё, что относится и к preg_match.
Так же, в preg_replace есть дополнительный, и довольно противоречивый, модификатор — PREG_REPLACE_EVAL, о котором говорится в документации
Так же, в preg_replace есть дополнительный, и довольно противоречивый, модификатор — PREG_REPLACE_EVAL, о котором говорится в документации
Непонятно, требуется ли экранировать спецсимволы в утверждениях для предшествующих символов, если идет или — |?
Пример
$str = '{Hello|there|and I should tell}'; preg_match_all('/(?<=\{|\||\S)\w+/ui', $str, $a);
Пример
$str = '{Hello|there|and I should tell}'; preg_match_all('/(?<=\{|\||\S)\w+/ui', $str, $a);
Обязательно.
Конструкция без слешей:
(?<={|||\S)\w+
Даст другой результат.
Но к тексту из вашего примера я бы просто применил explode и str_replace.
Вообще, регулярками не нужно разбрасываться во все стороны. Ими нужно пользоваться с умом.
Хоть регулярные выражения и обрабатываются нативной C-библиотекой, всё же это громоздкий механизм, потребляющий память и процессорное время.
Тут всё зависит от целей и задач.
Но если очень хочется именно регулярки, тогда так: (?<=\{|\||\S)[^\{|\|]+\w+
Тогда мы получим участки текста, разделенные |, а не каждое слово в отдельности, как в вашем варианте.
Если нужны просто участки текста, то можно обойтись и без всяких утверждений и сделать так — [^\{|\|]+\w+
Опять же — тут всё зависит от того, что вы будете дальше делать с текстом и с какой целью разделяете предложение.
А вообще, в официальной документации есть прекрасный материал по регулярным выражениям. Обязателен к ознакомлению.
Конструкция без слешей:
(?<={|||\S)\w+
Даст другой результат.
Но к тексту из вашего примера я бы просто применил explode и str_replace.
Вообще, регулярками не нужно разбрасываться во все стороны. Ими нужно пользоваться с умом.
Хоть регулярные выражения и обрабатываются нативной C-библиотекой, всё же это громоздкий механизм, потребляющий память и процессорное время.
Тут всё зависит от целей и задач.
Но если очень хочется именно регулярки, тогда так: (?<=\{|\||\S)[^\{|\|]+\w+
Тогда мы получим участки текста, разделенные |, а не каждое слово в отдельности, как в вашем варианте.
Если нужны просто участки текста, то можно обойтись и без всяких утверждений и сделать так — [^\{|\|]+\w+
Опять же — тут всё зависит от того, что вы будете дальше делать с текстом и с какой целью разделяете предложение.
А вообще, в официальной документации есть прекрасный материал по регулярным выражениям. Обязателен к ознакомлению.
Идеальный генератор вопросов для «Что? Где? Когда?».
Идеальный генератор вопросов для «Что? Где? Когда?».
Я — новичок в PHP, использую следующие связки
XAMPP (apache+mod_php) и WT-NMP (nginx+php_fastcgi)
всегда интересовал такой вопрос: парсинг каждого php-файла происходит при КАЖДОМ запросе web-сервера (при условии что php-скрипты не обновляются и динамически не генерируются)?
1. Если да, то каков оверхед в данном случае (примерно, и как его измерить)
2. Какое расширение необходимо подключить чтобы избежать такой «неразумной траты процессорного времени»?
3. Если расширение кеширования опкода будет установлено — как производить обновление php-скрипта?
XAMPP (apache+mod_php) и WT-NMP (nginx+php_fastcgi)
всегда интересовал такой вопрос: парсинг каждого php-файла происходит при КАЖДОМ запросе web-сервера (при условии что php-скрипты не обновляются и динамически не генерируются)?
1. Если да, то каков оверхед в данном случае (примерно, и как его измерить)
2. Какое расширение необходимо подключить чтобы избежать такой «неразумной траты процессорного времени»?
3. Если расширение кеширования опкода будет установлено — как производить обновление php-скрипта?
Если не установлены системы кеширования типа opcahe, apc или eaccelerator, то обработка php-файла осуществляется при каждом запросе.
Такие системы, как правило, либо сами определяют изменился ли файл, либо принудительно обновляют кеш через определённый промежуток времени.
Есть ещё вариант, когда сам браузер закешировал страницу, тогда обращения к серверу вообще не происходит :).
Такие системы, как правило, либо сами определяют изменился ли файл, либо принудительно обновляют кеш через определённый промежуток времени.
Есть ещё вариант, когда сам браузер закешировал страницу, тогда обращения к серверу вообще не происходит :).
2. Есть APC, Xcache, Zend Opcache. Предпочтительнее использовать последнее.
3. Обновление ОП-кэша это уже забота модуля, а не разработчика )
3. Обновление ОП-кэша это уже забота модуля, а не разработчика )
1) Да, оверхэд есть, зависит от количества файлов и т.д. То есть тут больше оверхэд за счет обращения к файловой системе, хотя и на парсинг много времени тратится
2) opcache, которое с версии PHP5.5 включено в ядро, и включено по умолчанию. Помимо простого кеширования опкодов, opcache так же делает внутренние оптимизации, так что споры аля что бы стрее, одинарные или двойные кавычки уже не актуальны, так как это влияет только на время разбора. Так же можно спокойно писать такие вот штуки:
opcache что может оптимизирует при первом разборе и если будет возможность вот такие вещи посчитать — он будет это делать. Хотя конечно там можно любой этап оптимизации отключить.
3. Заменили файлы, и все. У того же opcache неплохой механизм инвалидации кэша, позволяющий не париться. Валидность кэша по умолчанию проверяется не на каждый запрос а по какому-то тайм фрейму не большому.
Так же на больших нагрузках можно попросту отключить механизм инвалидации кэша и при деплойменте просто сбрасывать кэш. Но в целом opcache и так неплохо оптимизирует все эти штуки и не проверят невалидность кэша на каждый запрос. Ну и все это конфигурится.
Ну и еще хорошая практика — прогрев кэша при деплое.
2) opcache, которое с версии PHP5.5 включено в ядро, и включено по умолчанию. Помимо простого кеширования опкодов, opcache так же делает внутренние оптимизации, так что споры аля что бы стрее, одинарные или двойные кавычки уже не актуальны, так как это влияет только на время разбора. Так же можно спокойно писать такие вот штуки:
$someConstant = 14 * 360 * 1000;
opcache что может оптимизирует при первом разборе и если будет возможность вот такие вещи посчитать — он будет это делать. Хотя конечно там можно любой этап оптимизации отключить.
3. Заменили файлы, и все. У того же opcache неплохой механизм инвалидации кэша, позволяющий не париться. Валидность кэша по умолчанию проверяется не на каждый запрос а по какому-то тайм фрейму не большому.
Так же на больших нагрузках можно попросту отключить механизм инвалидации кэша и при деплойменте просто сбрасывать кэш. Но в целом opcache и так неплохо оптимизирует все эти штуки и не проверят невалидность кэша на каждый запрос. Ну и все это конфигурится.
Ну и еще хорошая практика — прогрев кэша при деплое.
Sign up to leave a comment.
Исследуем результат работы php-транслятора