![[info]](http://l-stat.livejournal.com/img/userinfo.gif?v=92.1){kind=small}
Все тесты у меня не заработали, но это и не важно, будем сравнивать с теми тестам что сработали сразу, а это: PHP mess, PHP includes и Smarty.
XSLT теста в комплекте не было, и я написал его, причем решил проверить что быстрее, xsl:for-each, или xsl:apply-templates.
По ходу создания шаблона (делал по образцу простого php) нашел и устранил несколько ошибок в HTML разметке (не закрытые и лишние тэги).
Входные данные брал не из PHP файла с массивами (data.inc), а сделал аналогичный XML файл (data.xml).
Результаты тестирования:
$ ab -n1000 -c30Сравниваемый параметр: Requests per second
php - 1670
php includes - 750
smarty - 320
XSLT foreach - 590
XSLT templates - 580
Чистый PHP всех кладет на лопатки, но там загружается лишь один файл, при использовании include скорость уже не намного выше чем у XSLT. Smarty оказался почти в два раза медленнее чем XSLT.
С небольшим отрывом xsl:for-each победил у xsl:apply-templates, поэтому не стоит полностью отказываться от xsl:for-each.
XSLT не самый быстрый шаблонизатор, но и не самый медленный, как его пытаются некоторые выставить. При этом предоставляемые удобства вполне компенсируют не очень быструю, сравнительную с самыми быстрыми шаблонизаторами, скорость.
На приведенном графике XSLT будет на уровне 200 (ZPS off), занимая "золотую середину" из всех шаблонизаторов.
Исходники тестов: lebowski-bench-xslt.zip
2008-12-18 07:12 (UTC)
А xsl:for-each и xsl:apply-templates для меня разные по применению конструкции: если первой я передвигаюсь по осям в основном, то вторую я использую как рекурсивный спуск, зачастую передавая параметры - ведь этот элемент работает прежде всего с детьми контекстного узла. Я понимаю, что вроде как контрукции взаимозаменяемы, но к примеру, чтобы пройтись по всем тегам b, я лучше напишу xsl:for-each select="//b" - это как-то читабельней что ли.
Хотя я ожидал, что for-each быстрее будет - он вроде как больше на итерацию, чем на рекурсию похож и без параметров к тому-же. Кстати, на вакансиях яндека был этот вопрос: который из этих двух быстрее и почему?
Еще, говоря о тестах, нельзя забывать, что каким бы ни был быстрым РНР, его все равно на клинта не переложишь :-)
2008-12-18 10:23 (UTC)
Ну пока и XSLT на клиенте не очень работает, хотя для некоторых проектов уже вполне можно применять, там где возможно навязать пользователям определенный браузер.
Рекурсия в XSLT очень быстрая, лучше применять ее чем работу с осями навигации. Мой конвертер abw2fb (из формата Abiword в FictionBook2) без рекурсии работал в сотни раз медленнее чем с оной (на больших файлах). Назначение программы - конвертация из плоской (похожей на HTML) структуры в древовидную, вместо <p style="Heading1"/> <p style="Heading2"/> и так далее нужно сделать дерево <section><section>. Наиболее быстрый метод - идти рекурсивно по одному тэгу в плоской структуре.
2008-12-18 11:15 (UTC)
XSLT array - 460
XSLT include - 510
Что не удивительно, множество XSLT файлов медленнее чем один, и преобразование Array to Dom работает медленнее чем парсинг XML файла.
P.S.: Архив с тестами обновлён.
2008-12-28 12:17 (UTC)
2008-12-28 13:35 (UTC)
Выложил по той же ссылке тест, где добавлено наиболее быстрое пребразование через функцию SimpleXMLElement(), оно используется в тестах "XSLT simple" и "XSLT simple include".
Скорость по сравнению с "XSLT foreach" (590) конечно же снизилась:
XSLT simple - 480
XSLT simple include - 420
2009-04-22 12:55 (UTC)
Потому что при apply-templates надо мало того, что сделать выборку , так еще и НАЙТИ нужный шаблон, среди всей той кучи шаблонов что существует для данного режима, причем чтобы выяснить что шаблон подходит, нужно ВЫПОЛНИТЬ операцию поиска соответствия для КАЖДОГО узла выборки.