Вот мое наблюдение, основанное на эмпирических данных. Я широко использую xslt, а во многих случаях в качестве альтернативы для процессоров данных, реализованных в Java. Некоторые из обработчиков данных, которые мы скомпилировали, немного сложнее. В первую очередь мы используем SAXON EE через редактор oxygenxml. Вот что мы заметили с точки зрения производительности преобразования.
Для менее сложных таблиц стилей xsl производительность довольно хорошая (2 секунды, чтобы прочитать файл объемом 30 МБ и сгенерировать
более 20 html-страниц с большим количеством структур div). и разница в производительности кажется примерно линейной или меньшей относительно изменения размера файла.
Однако, когда изменяется сложность таблицы стилей xsl, изменение производительности может быть экспоненциальным (тот же файл, с часто вызываемым вызовом функции, вызываемым в шаблоне, с функцией, реализующей простое разрешение xpath, может изменить время обработки, для одного и того же файла, от 2 до 24 с) И кажется, что введение функций и вызовов функций, кажется, является основным виновником.
Тем не менее, мы не сделали детального обзора производительности и оптимизации кода. (все еще в альфа-режиме, и производительность все еще в наших пределах - т.е. пакетная работа). Я должен признать, что у нас может быть «злоупотребленная» функция xsl, поскольку во многих местах мы использовали идею абстракции кода в функции (в дополнение к использованию шаблонов). Я подозреваю, что из-за природы, в которой вызываются шаблоны xslt, возможна большая рекурсия в процедурах реализации (для процессора xslt), и вызовы функций могут стать дорогими, если они не оптимизированы. Мы думаем, что изменение «стратегии» в том, как мы пишем наши xsl-скрипты (чтобы быть более ориентированным на XSLT / XPATH), может помочь производительности процессора xlst. Например, использование ключей xsl. так что да, мы, возможно, так же виноваты, как заряженный процессор:)
Еще одна проблема с производительностью - использование памяти. Хотя технически ОЗУ не является проблемой, но простой процессор, увеличивающий с 1 ГБ (!!!) до 6 ГБ для одного вызова / преобразования, не совсем кошерный. Там может быть проблема масштабируемости и емкости (в зависимости от приложения и использования). Это может быть связано не столько с базовым процессором xlst, сколько с инструментом редактора. Это, по-видимому, оказывает огромное влияние на отладку таблиц стилей в реальном времени (т. Е. Пошаговое выполнение xslt).
Несколько замечаний:
- командная строка или «производственный» вызов процессора имеет лучшую производительность
- для последовательных прогонов (с использованием процессора xslt) первый прогон занимает самое длинное (скажем, 10 с), а последовательные прогоны занимают намного меньше (скажем, 4 с). Снова, возможно, что-то связано со средой редактора.
Тем не менее, хотя производительность процессоров может временами быть проблемой, и в зависимости от требований приложения, я считаю, что если учесть другие факторы, уже упомянутые здесь, такие как сопровождение кода, простота реализации, быстрые изменения размер базы кода, проблемы с производительностью могут быть смягчены или могут быть «приняты» (если конечное приложение все еще может жить с числами производительности) при сравнении реализации с использованием XSLT против Java (или других)
... прощайте! * * 1013