Есть неплохой пример использования re2c в большом проекте: функция unserialize() в PHP написана с использованием re2c.
В исходниках PHP это ext/standard/var_unserializer.re и соответствующий ext/standard/var_unserializer.c, ну и на сайте PHP есть указание на re2c.
Когда одним скриптом (ну, точнее, одним вызовом) генерируется большая HTML-страница — то % времени на чтение конфигов маленький. Ну, например, 1/1000 времени работы скрипта.
Когда скриптом генерируются картинки, то, возможно, чуть больше (зависит от многих условий, понятное дело). Условно, потому что картинки генерируются графическими библиотеками, там PHP-вызовов меньше.
Когда скриптом генерируются AJAX-ответы — то, бывает, еще больше.
Например, я недавно видел подобный скрипт, который позволял реализовать часы в браузере: время на часах через AJAX-запросы к серверу синхронизировалось с серверным. Так вот, чтобы отдать клиенту текущее время, скрипт предварительно лез в конфиги, чтобы посмотреть формат времени-даты. Это, конечно, можно считать мисдизайном, потому что формат можно было принимать от клиента. Но это как посмотреть.
Так вот, это я к чему… Чтение конфигов в этом скрипте составляло что-то около 90% времени. А запросов к нему было достаточно много (больше, чем к страницам). А теперь представьте, что этот скрипт случайно был бы включен в phpBB, и конфиги бы хранились в базе данных…
Отсюда и интерес к исследованию скорости: чем меньше скрипты и чем больше раз они вызываются, тем более оптимизированы они должны быть.
В случае конфигов на PHP это не обязательно. Даже если злоумышленник найдет config.php и откроет его через браузер, он увидит пустую страничку.
Кроме этого, доступ к конфигам можно ограничивать через настройки сервера (как вариант, .htaccess).
Но, в сущности, Вы правы — защищать конфиги — первое дело каждого программиста.
С последним пунктом однозначно соглашусь — код должен генерировать по минимуму warning'ов и даже notice'ов. Но задача была оптимизировать работу скриптов по максимуму, избежать лишних проверок, и т.п. Чтобы не было «тормозов» из-за этих проверок. Поэтому код получился именно «тестовый», а не рабочий.
> кофиги нужно хранить в удобном виде, а затем кэшировать в шареную память: smop, apc, memcache…
Вообще-то да. Но сколько % людей, которые программируют на PHP, так делают?
> подход ни о чём. куча слов о железе
Ровно 1 предложение о железе было добавлено после того, как получено достаточно комментариев открыто и в личку
> но сейчас нет ничего о том, как делались замеры
Еще я не написал, что мой любимый редактор — Vim. Мне показалось это излишней информацией. А Вы из этого сделали вывод, что исследование и подход ни о чем
> тестировать лучше сторонними утилитами и парокой левых инклудов
Почему сторонними? Тогда ведь нужно считать время старта PHP-интерпретатора. Я тестировал из командной строки, время считалось вызовами microtime() до и после 1000 итераций загрузки конфигов
> чтобы исключить влияние файлового кэша ОС. например, ab с конкурентными запросами, как в реальной жизни.
А почему его нужно исключать?.. В реальной жизни же все используют кэш ОС. И если какой-то из алгоритмов использует его более эффективно — то ура, товарищи!
Насчет file():
Попробовал, на маленьких файлах получается чуточку быстрее, на больших — медленнее.
Спасибо, как освобожусь — включу в статью дополнение
В исходниках PHP это ext/standard/var_unserializer.re и соответствующий ext/standard/var_unserializer.c, ну и на сайте PHP есть указание на re2c.
Когда одним скриптом (ну, точнее, одним вызовом) генерируется большая HTML-страница — то % времени на чтение конфигов маленький. Ну, например, 1/1000 времени работы скрипта.
Когда скриптом генерируются картинки, то, возможно, чуть больше (зависит от многих условий, понятное дело). Условно, потому что картинки генерируются графическими библиотеками, там PHP-вызовов меньше.
Когда скриптом генерируются AJAX-ответы — то, бывает, еще больше.
Например, я недавно видел подобный скрипт, который позволял реализовать часы в браузере: время на часах через AJAX-запросы к серверу синхронизировалось с серверным. Так вот, чтобы отдать клиенту текущее время, скрипт предварительно лез в конфиги, чтобы посмотреть формат времени-даты. Это, конечно, можно считать мисдизайном, потому что формат можно было принимать от клиента. Но это как посмотреть.
Так вот, это я к чему… Чтение конфигов в этом скрипте составляло что-то около 90% времени. А запросов к нему было достаточно много (больше, чем к страницам). А теперь представьте, что этот скрипт случайно был бы включен в phpBB, и конфиги бы хранились в базе данных…
Отсюда и интерес к исследованию скорости: чем меньше скрипты и чем больше раз они вызываются, тем более оптимизированы они должны быть.
Извините за написанный на скорую руку код :-)
Кроме этого, доступ к конфигам можно ограничивать через настройки сервера (как вариант, .htaccess).
Но, в сущности, Вы правы — защищать конфиги — первое дело каждого программиста.
Я вот чисто для интереса поисследовал :-)
Да, такие большие конфиги я не рассматривал
Позвольте с Вами не согласиться
> кофиги нужно хранить в удобном виде, а затем кэшировать в шареную память: smop, apc, memcache…
Вообще-то да. Но сколько % людей, которые программируют на PHP, так делают?
> подход ни о чём. куча слов о железе
Ровно 1 предложение о железе было добавлено после того, как получено достаточно комментариев открыто и в личку
> но сейчас нет ничего о том, как делались замеры
Еще я не написал, что мой любимый редактор — Vim. Мне показалось это излишней информацией. А Вы из этого сделали вывод, что исследование и подход ни о чем
> тестировать лучше сторонними утилитами и парокой левых инклудов
Почему сторонними? Тогда ведь нужно считать время старта PHP-интерпретатора. Я тестировал из командной строки, время считалось вызовами microtime() до и после 1000 итераций загрузки конфигов
> чтобы исключить влияние файлового кэша ОС. например, ab с конкурентными запросами, как в реальной жизни.
А почему его нужно исключать?.. В реальной жизни же все используют кэш ОС. И если какой-то из алгоритмов использует его более эффективно — то ура, товарищи!
Попробовал, на маленьких файлах получается чуточку быстрее, на больших — медленнее.
Спасибо, как освобожусь — включу в статью дополнение
Спасибо, как освобожусь — включу в статью дополнение
Время считается для цикла из 1000 загрузок конфига. А у Вас генерируется 1 страница