Использовать случай для XSL Streaming на небольшом документе, отличном от раннего выхода?

Question

Я изучаю варианты использования потоковой передачи в XSL. Я знаю два очевидных случая:

A. Вам нужно преобразовать очень большой документ, который не может храниться в памяти. B. Вам нужна только небольшая часть документа, и часто эта маленькая часть находится рядом с верхней частью. Затем вы можете сэкономить время через ранний выход.

Я пишу, чтобы спросить, на практике, есть третий реальный случай использования:

C. У вас есть простое преобразование и хотите отказаться, необходимое для построения дерева XML процессорного времени. Для примера, представьте поставки в магазине хранятся в структуре XML в следующем формате:

верхнего уровня = год

2-й уровень = месяц

3-го уровня = День отгрузки

4-й уровень = Пересылка ID

пятого уровня = Отдельные элементы в отгрузке

Ю. для примера рассмотрим преобразование, целью которого является вытащить информацию на уровне «месяц» .... нужны только данные, хранящиеся в атрибутах элементов месяца, и не нуждающиеся в информации о потомках этих узлов.

Возможно ли, что такое преобразование может извлечь выгоду из потоковой передачи, хотя весь документ должен быть прочитан? Я надеялся, что может быть достигнуто некоторое время, потому что нет необходимости строить деревья, но в моем ограниченном тестировании кажется, что это не так.

Я попробовал такой пример в SAXON 9.5.1.3, а потоковая передача была примерно на 20% медленнее, чем пример без потоковой передачи. Возможно, накладные расходы, связанные с выполнением потоковой передачи, почти всегда будут хуже, чем время, затраченное на не создание деревьев? (По крайней мере, в SAXON, где построение дерева происходит очень быстро.)

Или я делаю ошибку в своем тестировании, и есть ясные примеры, когда потоковая передача более эффективна, даже когда весь документ должен быть прочитан?

Answer 1

Спасибо за данные о Саксонии. Я не удивлен 20% накладными расходами; Я бы не удивился, если бы это было 60%. Значительная часть этого имеет отношение к зрелости реализации; это достаточно сложно, чтобы начать работать с потоком, прежде чем вы начнете думать о том, чтобы сделать это быстро. Но я был бы удивлен, если бы он стал значительно быстрее обычной обработки в случае документов, которые достаточно малы для обработки в памяти. Отчасти это связано с тем, что при выполнении преобразований, которые вы можете использовать с потоковой передачей, вероятно, будут доминировать затраты на синтаксический анализ и сериализацию, что в обеих моделях одинаково.

Я знаю несколько областей, где есть возможность для оптимизации (или, по крайней мере, для подробного измерения, чтобы определить, есть ли область для оптимизации), но приоритет заключается в том, чтобы все это работало и получило достаточный объем теста что можно оптимизировать, не рискуя ввести больше ошибок.

Answer 2

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

Это может быть преимуществом в некоторых случаях, даже если пропускная способность (время завершения обработки документа) несколько снижается.

Я не уверен в внутренности Саксона, но Xalan уже давно предлагает режим «инкрементного разбора», который был предназначен для разрешения такого же компромисса; в некоторых случаях это может уменьшить задержку, но добавило некоторые накладные расходы для отслеживания того, сколько данных было проанализировано до сих пор, поэтому пропускная способность может быть уменьшена.

Выберите режим, который имеет смысл для вашего приложения. Инструменты для задач ...

(я бы еще хотел бы видеть, как кто-то выбирает концепцию оптимизации потоковой оптимизации, которую запатентовал IBM. Это самый общий подход, который я еще видел для распознавания потоковой передачи возможности оптимизации в неограниченном XSLT. Увы, работа с более высоким приоритетом отвлекала ресурсы, необходимые для доставки от прототипа к качеству производства, и я не нашел личного времени для попытки версии skunkworks.)