Facebook XHP. Объектный шаблонизатор
Несмотря на то, что Facebook анонсировал XHP еще в феврале 2010 года, до сих пор об этом шаблонизаторе очень мало информации, хотя даже как идея XHP весьма и весьма интересен.В этой статье я попытаюсь дать краткий обзор XHP, основные плюсы и минусы, а также затрону вопросы производительности.
XHP — это расширение PHP, которое дополняет синтаксис языка, с одной стороны улучшая воспринимаемость front-end кода и с другой — помогая избегать XSS-атак. [1]
Итак, что нам нужно, чтобы вывести немножко HTML (XML)-разметки?
Если грубо, то потребуется следующее:
// генерируем HTML
$html = '
Привет, Хабр!
$html =
Привет, Хабр!
$html = new: div (array ('id'=>'mydiv',), new: p (array (), 'Привет, Хабр!')); echo $html; Думаю, что после данных примеров, большинству уже стало понятно, что «XML» транслируется расширением XHP в некие классы, которые описывают html-element.В этом по большему счету и есть вся суть XHP-шаблонизатора. Теперь вы не работаете со «строковым HTML». От слова «совсем», поскольку каждая нода -это некий объект со своими свойствами.
Дополнительно ко всему, любой пользовательский контент экранируется, т.е. для любой дочерний элемент, не являющийся html-element автоматически обрабатывается htmlspecialchars. Да, и ваш контент, полученный из базы данных, тоже будет по умолчанию экранирован, поверьте, так лучше для вас.
PHP:
$html = »
$html =
$html = new myHtml (; Значит и оставить не закрытые, с неправильной вложенностью html-element’ы не сможете (short tags поддерживаются).Теперь о минусах Единственным очевидным минусом вышеописанной схемы является то, из чего проистекают её плюсы — каждый элемент — это объект.Соответственно layout из 2000 вложенных тэгов — это 2000 вложенных объектов.
Что мы получим на выходе ясно:
Повышенный расход памяти Снижения быстродействия Повышенный расход памяти затрагивать особого смысла в рамках данной статьи не вижу, т.к. XHP-объекты достаточно простые, а памяти под процесс выделяется достаточно много (640 килобайт хватит всем ©).Но создание множества вложенных объектов и преобразование XHP-разметки в объекты должно увеличить время рендеринга. Вопрос — на сколько?
К счастью, некто Расмус Лердорф еще в 2010 году провел сравнительный анализ «скорострельности» XHP vs PHP native и получил следующие результаты [2]:
PHP: деградация ~97% (30 rps — 1300 rps) PHP+APC: деградация ~75% (330rps — 1460 rps) Поскольку это было давно и неправда тесты получились несколько синтетические — генерировался мизерный фрагмент HTML (форма), я решил, что нужно провести сравнительные тесты на HHVM (в которую поддержка XHP встроена «из коробки», для PHP придется собирать отдельный модуль).
К сожалению, описание всех XHP-классов так и осталось в php-файлах (Расмус писал, что возможно проблему низкой производительности можно частично нигилировать переносом объявлений базовых классов в скомпилированный модуль), для Hack авторы предлагают лишь заменить
И, естественно, для рендеринга я взял не 4–5 тэгов, а полноценный Layout. Настройки siege аналогичны тем, что в примере у Расмуса.
HHVM + XHP
siege -c 3 -b -t30s http://****.ru Transactions: 6003 hits Availability: 100.00% Elapsed time: 29.54 secs Data transferred: 8.80 MB Response time: 0.01 secs Transaction rate: 203.22 trans/sec Throughput: 0.30 MB/sec Concurrency: 3.00 Successful transactions: 6003 Failed transactions: 0 Longest transaction: 0.03 Shortest transaction: 0.00 HHVM + PHP
siege -c 3 -b -t30s http://****.ru Transactions: 19583 hits Availability: 100.00% Elapsed time: 29.96 secs Data transferred: 33.22 MB Response time: 0.00 secs Transaction rate: 653.64 trans/sec Throughput: 1.11 MB/sec Concurrency: 2.99 Successful transactions: 19583 Failed transactions: 0 Longest transaction: 0.02 Shortest transaction: 0.00 Деградация около 68%. Лучше, чем 75%, но всё равно относительно много.Почему «относительно»? Потому что тестовое «приложение» состояло только из View, без обращения к БД, без бизнес-логики и прочего.В реальности же может получиться, что деградация производительности на этапе рендеринга View в процентном соотношении будет ничтожной на фоне остальной части приложения.
В конце-концов вопрос выбора того или иного шаблонизатора остаётся за архитектором системы.
Информация для ознакомления:
XHP: A New Way to Write PHP by Facebook A quick look at XHP by Rasmus Lerdorf XHP on GitHub
