В ряде Symfony-проектов у нас используется hstore. Для тех, кто не в курсе, hstore — это PostgreSQL-модуль, позволяющий сохранять массивы значений в одном поле. Мы накидали отдельны DBAL-тип
Оформлено все в Symfony-бандл Intaro\HStoreBundle. Но речь в целом не о бандле. Речь о том, как мы попробовали оптимизировать его с помощью Zephir.
Дело в том, что бандл использует HStoreParser, преобразующий строковые представления массивов значений, которые приходят из PostgreSQL, в PHP-объекты. И парсинг начинает выполняться значительное время, когда нам нужно вывести большое количество записей из БД, в которых есть поля hstore, и в каждом из полей хранятся десятки значений.
С похожей проблемой в свое время столкнулись разработчики шаблонизатора Twig, когда у них проседала по времени одна очень часто используемая функция. Они решили проблему портированием в C-extension для PHP.
Мы решили тоже попробовать данный подход, но реализовали не на чистом C, а используя Zephir. На то, чтобы разобраться в синтаксисе Zephir, развернуть его и портировать класс
Для оценки профита и проверки идентичности поведения классов подготовили тестовый набор hstore-данных и тест. Прогон осуществлялся на машине 2 GHz Intel Core i7 с PHP 5.4.26.
Результаты прогона получились следующие:
Кроме того Zephir-код можно еще улучшить, когда появятся некоторые ожидаемые возможности (передача параметров по ссылке, внутренние статические переменные класса, замыкания).
В сухом остатке. Zephir-реализация медленных участков кода может быть эффективна при этом не требует сильного переписывания кода. В целом, даже по силам поддерживать PHP- и Zephir-реализации параллельно, чтобы проект работал как на чистом PHP, так и с C-extensions.
UPD Обновил показатели по PHP HStoreParser, исходный прогон был сделан с включенным xdebug.
hstore, а также тип поля hstore для Doctrine ORM, для прозрачного работы с такого рода полями. Оформлено все в Symfony-бандл Intaro\HStoreBundle. Но речь в целом не о бандле. Речь о том, как мы попробовали оптимизировать его с помощью Zephir.
Дело в том, что бандл использует HStoreParser, преобразующий строковые представления массивов значений, которые приходят из PostgreSQL, в PHP-объекты. И парсинг начинает выполняться значительное время, когда нам нужно вывести большое количество записей из БД, в которых есть поля hstore, и в каждом из полей хранятся десятки значений.
С похожей проблемой в свое время столкнулись разработчики шаблонизатора Twig, когда у них проседала по времени одна очень часто используемая функция. Они решили проблему портированием в C-extension для PHP.
Мы решили тоже попробовать данный подход, но реализовали не на чистом C, а используя Zephir. На то, чтобы разобраться в синтаксисе Zephir, развернуть его и портировать класс
HStoreParser ушло объективно немного времени. Из больших преимуществ Zephir то, что реализация на нем достаточно сильно похожа на исходную PHP-реализацию. Для сравнения реализация на PHP и на Zephir.Для оценки профита и проверки идентичности поведения классов подготовили тестовый набор hstore-данных и тест. Прогон осуществлялся на машине 2 GHz Intel Core i7 с PHP 5.4.26.
Результаты прогона получились следующие:
- PHP HStoreParser: 614.228963852 ms for 1000 strings
- Zephir HStoreParser: 432.605981827 ms for 1000 strings
Кроме того Zephir-код можно еще улучшить, когда появятся некоторые ожидаемые возможности (передача параметров по ссылке, внутренние статические переменные класса, замыкания).
В сухом остатке. Zephir-реализация медленных участков кода может быть эффективна при этом не требует сильного переписывания кода. В целом, даже по силам поддерживать PHP- и Zephir-реализации параллельно, чтобы проект работал как на чистом PHP, так и с C-extensions.
UPD Обновил показатели по PHP HStoreParser, исходный прогон был сделан с включенным xdebug.
