Какая самая быстрая система шаблонов для Python?

Jinja2 и Mako, по-видимому, довольно быстры.

Как они соотносятся с (менее популярными, но, вероятно, достаточно хорошими для того, что я делаю) string.Template ?


person Josh Gibson    schedule 24.08.2009    source источник
comment
сравнивать? Хотите сравнить скорость? Ребята из дзиндзя говорят, что string.Template работает быстрее. Что еще нужно знать? Или вы хотите сравнить какой-то другой аспект?   -  person S.Lott    schedule 24.08.2009
comment
Вам, вероятно, все равно, насколько быстра система шаблонов. Среди популярных все они имеют вполне приемлемые ТТХ. Пожалуйста, принимайте такие решения, основываясь на более важных вещах, таких как простота программирования.   -  person Christian Oudard    schedule 25.08.2009
comment
Это зависит, правда. Там, где я работаю, мы обслуживаем множество шаблонов в секунду, и у нас есть армия высококвалифицированных программистов и дизайнеров, поэтому в этом контексте скорость важнее простоты программирования. Более того, я бы сказал, что простота чтения важнее простоты программирования.   -  person gb.    schedule 28.03.2012
comment
@Эмиль, эй, почему откат?   -  person anatoly techtonik    schedule 18.01.2013
comment
@techtonik Если у вас есть дополнительная информация для добавления, вы можете сделать это в новом ответе — изменение фактического содержания ответа считается плохой практикой :)   -  person Emil    schedule 19.01.2013
comment
@ Эмиль, картинка не добавляет больше информации, но делает ответ более аргументированным.   -  person anatoly techtonik    schedule 31.01.2013
comment
@techtonik На мой взгляд, аргументация в ответе соответствует оригинальному плакату. Прочтите эту статью о редактировании.   -  person Emil    schedule 31.01.2013
comment
@Emil - я прочитал статью только для того, чтобы подтвердить, что мое редактирование соответствует хорошей практике редактирования - Clarify meaning without changing it. и Add related resources or links.. Как вы можете видеть из комментария, набравшего наибольшее количество голосов, ссылка полезная, поэтому я добавил изображение на случай, если ссылка исчезнет. Позвольте мне также сказать, почему я отклонил ваше редактирование - нет никакого объяснения, почему вы возвращаетесь, и даже после прочтения статьи, на которую вы ссылаетесь, я не вижу никаких оснований для возврата. Я позволяю этому быть на вашем пути, даже если вы не автор, просто потому, что это не стоит хлопот. знак равно   -  person anatoly techtonik    schedule 31.01.2013
comment
@techtonik Я не буду обсуждать это дальше, но вы указали на мою точку зрения: главный комментарий. Комментарии предназначены для добавления соответствующей информации или обсуждения ее содержания. Не стесняйтесь редактировать, как вам нравится, мой откат мог быть чрезмерным. :)   -  person Emil    schedule 31.01.2013
comment
@ChristianOudard, все они имеют вполне приемлемые характеристики производительности… за исключением того, что ни один из них не имеет контролируемых точек сброса, а это означает, что ни один из них не подходит для моего случая использования для создания и потоковой передачи больших RSS-каналов. Мако занимал до минуты, тайм-аут был 30 секунд. Никто ничего не получит, а сервер при этом будет абсолютно перегружать оперативную память. Написал новый механизм шаблонов (cinje) с явным : flush, и теперь наши каналы начинают транслироваться мгновенно, и занимает не более 20 секунд в общей сложности.   -  person amcgregor    schedule 03.07.2019


Ответы (5)


Вот результаты популярных шаблонизаторов для рендеринга HTML-таблицы размером 10x1000.

Python 2.6.2 on a 3GHz Intel Core 2

Kid template                         696.89 ms
Kid template + cElementTree          649.88 ms
Genshi template + tag builder        431.01 ms
Genshi tag builder                   389.39 ms
Django template                      352.68 ms
Genshi template                      266.35 ms
ElementTree                          180.06 ms
cElementTree                         107.85 ms
StringIO                              41.48 ms
Jinja 2                               36.38 ms
Cheetah template                      34.66 ms
Mako Template                         29.06 ms
Spitfire template                     21.80 ms
Tenjin                                18.39 ms
Spitfire template -O1                 11.86 ms
cStringIO                              5.80 ms
Spitfire template -O3                  4.91 ms
Spitfire template -O2                  4.82 ms
generator concat                       4.06 ms
list concat                            3.99 ms
generator concat optimized             2.84 ms
list concat optimized                  2.62 ms

Тест основан на коде тестов производительности Spitfire с некоторыми добавленными механизмами шаблонов и добавленными итерациями для повышения точности. Список и генератор concat в конце написаны вручную на Python, чтобы почувствовать верхний предел производительности, достижимый при компиляции в байт-код Python. Оптимизированные версии используют интерполяцию строк во внутреннем цикле.

Но прежде чем вы решите сменить механизм шаблонов, убедитесь, что это имеет значение. Вам нужно будет выполнить довольно тяжелое кэширование и действительно оптимизировать код, прежде чем различия между механизмами компиляции шаблонов начнут иметь значение. Для большинства приложений хорошие средства абстракции, совместимость с инструментами проектирования, знакомство и другие вещи имеют гораздо большее значение.

person Ants Aasma    schedule 25.08.2009
comment
Я не знал, что шаблон Django такой медленный. - person Joshua Partogi; 25.08.2009
comment
Я тоже не знал. Для большинства это небольшая часть уравнения, но если вы визуализируете таблицу данных 10x1000, у вас проблемы. - person orokusaki; 19.09.2010
comment
Это сравнение, конечно, сильно зависит от того, что вы делаете. Что, если вы визуализируете множество маленьких шаблонов, а не одну массивную таблицу? Тогда станут актуальными совершенно другие характеристики производительности механизма шаблонов, такие как синтаксический анализ шаблона и время загрузки. Мораль? Принимайте решения по оптимизации на основе собственных тестов собственного кода. - person Carl Meyer; 28.02.2011
comment
Да, у Tenjin время загрузки каждого рендера составляет 3 мс, в моем случае на форуме с ветками комментариев Cheetah занимает 0,4 мс для 1 комментария, а у tenjin — 3 мс, при 50 комментариях tenjin и cheetah встречаются за 5 мс. При 5000 тенджин составляет 40 мс, а при гепарде - 250 мс. - person ; 31.07.2013
comment
У меня есть собственная копия теста bigtable (10x1000), используемого для бенчмаркинга, написав мой собственный двигатель после того, как обнаружил, что все остальные колеса были квадратными (нет промывки в середине потока, неоптимальная производительность, веселая сложность). Если для вас важно значение TTFB, 0,02 мс (47 938 ген/с), кажется, уверенно выигрывает самый быстрый значок. (Против 50 ген/сек у Тенджина) - person amcgregor; 12.12.2018
comment
Можно ли обновить ответ, чтобы получить обновленные результаты тестов из здесь? - person AmeyaVS; 27.03.2019
comment
@AmeyaVS Набор результатов теста 10-летней давности должен быть обновлен набором результатов теста 4-летней давности, созданным в версии Python, которой больше не существует? Лучше было бы запустить набор тестов локально для реального сравнения с выбранной вами реальной средой выполнения. Кроме того, могут быть более быстрые варианты подходов, которые быстрее из-за снижения безопасности, что может быть приемлемым, ссылка: результаты теста *_unsafe из моей ранее предоставленной ссылки на страницу результатов. Наконец, что более важно, IMO, это время до первого байта (TTFB), поэтому результаты *_flush_first. - person amcgregor; 13.01.2020

Из документов jinja2 кажется, что string.Template является самым быстрым, если это все, что вам нужно. .

Без сомнения, вы должны попытаться удалить из шаблонов как можно больше логики. Но шаблоны без всякой логики означают, что всю обработку приходится делать в коде, что скучно и глупо. Механизм шаблонов, который делает это, поставляется с Python и называется string.Template. Поставляется без циклов и условий и, безусловно, является самым быстрым механизмом шаблонов, который вы можете получить для Python.

person Josh Gibson    schedule 24.08.2009

Если вы можете добавить кеширование (например, memcached), то выбирайте на основе функций и простоты использования, а не оптимизации.

Я использую Mako, потому что мне нравится синтаксис и функции. К счастью, он также является одним из самых быстрых.

person Tony    schedule 09.11.2009
comment
Раньше мы использовали шаблоны Mako, пока наши многомегабайтные RSS-каналы не начали генерироваться вовремя (‹30 сек.), поскольку Mako буферизует весь ответ, наши пользователи не получали абсолютно ничего в ответ, а нехватка памяти была чрезвычайно высокой. Это также не особенно быстро. Он относится к тому же классу, что и движок Bottle. , или Tenjin, но бледнеет по сравнению с моим собственным, который поддерживает промывку в середине потока. (48 ген/с против 47 937 генер/с.) (Теперь, даже если для создания фида требуется больше 30 секунд, он не истекает по тайм-ауту и ​​транслируется.) - person amcgregor; 19.04.2019

В общем, вам придется выполнить профилирование, чтобы ответить на этот вопрос, так как это зависит от того, как вы используете шаблоны и для чего.

string.Template является самым быстрым, но настолько примитивным, что его вряд ли можно назвать шаблоном в том же духе, что и другие системы шаблонов, поскольку он выполняет только замену строк и не имеет условий или циклов, что делает его практически бесполезным.

person Lennart Regebro    schedule 24.08.2009

Я думаю, что Cheetah может быть самым быстрым, так как он реализован на C.

person Koen Bok    schedule 25.08.2009
comment
То, что что-то написано на C, не означает, что оно будет быстрее; Эти вещи сильно зависят от разработчика. - person kzh; 03.06.2010
comment
Да что кж правда. Кроме того, Cheetah написан не на C, а на Python. Однако небольшая его часть, преобразователь имен, может при желании использовать гораздо более быструю скомпилированную версию C. - person Ben Hoyt; 16.02.2011
comment
Однажды я написал сервер HTTP/1.1 на Python. Для нормализации имен заголовков, которые в WSGI должны быть ALL_UPPER_UND_SEP (а-ля CGI), я подумал, господи, код C должен быть эффективным для этого, поэтому я позаимствовал соответствующий модуль C из Rack или другого веб-сервера Ruby. Это было 1000 строк C, сгенерированных машиной из Ruby. Python работал существенно быстрее, чем скомпилированный C, несмотря на повторные .replace() вызовы и цепочки других фильтров (upper и т. д.), и был бесконечно проще для понимания. - person amcgregor; 26.03.2019
comment
Ах, да, я также укажу на тесты для конкретных шаблонов. Cheetah является одним из самых худших исполнителей в тесте с большой таблицей, то есть генерации одного <table> с 10 столбцами и 1000 строками из статического списка диктов. Чуть меньше 10 генераций в секунду. Любой современный парсер Движки /generator превосходят его (даже Mako в 2 раза быстрее), а мой собственный метод потоковой генерации оставляет его далеко позади. (Чуть менее 48 000 поколений в секунду: таким образом, производительность Cheetah составляет 0,02%, а не 2%. 0,02%.) - person amcgregor; 19.04.2019