Производительность XSLT-преобразования в .net

Question

Наши программы часто связываются с другими системами для получения данных, и часто происходит копирование данных из контрактов, выставленных другими системами в соответствии с требуемым шаблоном контрактов приложений.Итак, мы создали утилиту, которая принимает XSLT-файл, и это сделает преобразование в требуемый объект.Поэтому, кто бы ни разрабатывал новый модуль, он просто должен предоставить файл XSLT.Теперь я чувствую, что есть Хит производительности, особенно когда входящий объект немного больше, а когда он будет сериализован для преобразований, он будет еще больше и займет много памяти.Так есть ли способ оптимизировать это дальше?Я использую скомпилированное преобразование XSLT. Это лучше, чем обычное преобразование?или есть какой-то другой способ улучшить производительность?Добрый совет

Answer 1

Поскольку в .NET 3.5 имеется xsltc.exe http://msdn.microsoft.com/en-us/library/bb399405.aspx в составе пакета .NET Framework SDK, он позволяет предварительно скомпилировать таблицу стилей XSLT, чтобы сократить объем работы, которую обычно приходится выполнять XslCompiledTransform при загрузкеТаблица стилей XSLT как документ XML.Я не знаю, подходит ли вам этот вариант, поскольку вы, кажется, получаете в качестве входных данных различные таблицы стилей XSLT.Что касается потребления памяти, XSLT (1.0, а также 2.0) работает на модели дерева в памяти полных входных документов XML, поэтому вы не можете сделать что-либо, чтобы сохранить низкое использование памяти с большими входными документами, кроме разрешения XSLT.Процессор выбирает свою любимую реализацию дерева.В случае XslCompiledTransform это XPathDocument в System.Xml.XPath.

Другие варианты, которые вы можете изучить, - это переход на стороннюю версию XSLT 2.0 (XQSharp, Saxon 9) или даже на 3.0 реализации, такие как Saxon 9.3, какSaxon 9.3 имеет потоковый режим http://www.saxonica.com/documentation/sourcedocs/streaming.xml, который может помочь сохранить низкое использование памяти при обработке больших или очень больших входных документов.

Answer 2

Теперь я чувствую, что есть представление Хит особенно когда входящий объект немного больше, и когда он получить сериализацию для преобразований это будет еще больше и занимать много памяти. Так есть ли способ оптимизировать это дальше?.

Это не конкретный вопрос, так как любой вопрос, связанный с производительностью, должен быть .

Необходимо выполнить измерения для выявления любых существующих узких мест и только затем рассмотреть возможность их оптимизации.

Или, цитируя Дональда Кнута :

«Преждевременная оптимизация - корень все зло "

Объект XmlDocument или XPathDocument вообще не нуждается в сериализации, чтобы иметь возможность выполнять XSLT-преобразование. Существует ряд перегрузок метода Transform() для XslCompiledTransform, которые принимают аргумент IXPathNavigable.

Я использую скомпилированное преобразование XSLT. это лучше, чем обычное преобразование

В .NET нет ничего, что называется "нормальным преобразованием". Вы, вероятно, имеете в виду класс Transform. Если так, то ответ таков: этот класс использовался в .NET1.1 и устарел с пяти лет назад. Класс XslCompiledTransform должен использоваться для преобразований XSLT 1.0. Это один из самых быстрых процессоров XSLT 1.0 от всех существующих поставщиков.