На что тратится время?
Обсуждение данного вопроса полезно начать с анализа того, на что процессор XSLT тратит свое время. Конечно, это зависит от особенностей обсуждаемой проблемы. В диаграммах на рисунках 3.1 и 3.2 показан анализ распределения времени для двух конкретных задач преобразования. На первом рисунке представлена работа, заключающаяся в представлении XML-версии спецификации XSLT в виде текста HTML; а процесс, показанный на другом рисунке, использует ту же самую таблицу стилей, но применяет ее к документу, намного меньшему по объему. Результаты, приведенные на диаграммах, были получены при использовании Saxon 6.5.2.
На рисунке 3.1 показано распределение времени, потраченного на четыре основных действия при применении таблицы стилей к большому документу: компилирование таблицы стилей, создание дерева исходного документа, выполнение самого преобразования и приведение в последовательную форму дерева результата в виде HTML. В этом случае объем таблицы стилей составляет около 1350 строк, разделенных на три модуля; исходный документ имеет размер 600 Кб, а документ результата – 860 Кб. Полное время преобразования на моей машине составило приблизительно 8,3 секунды. В Saxon три стадии выполняются последовательно: компилирование, создание дерева и преобразование/приведение в последовательную форму. Распределение времени между преобразованием и приведением в последовательную форму рассчитано путем сравнения времени выполнения процессов без приведения в последовательную форму HTML (только с передачей результата написанному пользователем обработчику содержания, который ничего с ним не делает).
Этот вид преобразования обычно выполняется один раз. Может быть получена только небольшая выгода с использованием предварительной компиляции таблицы стилей и амортизации затрат времени на компиляцию при многократных преобразованиях различных источников документов, так как экономия времени, которая может быть достигнута этим способом, составила бы в лучшем случае 15 процентов. Общее количество затраченного времени (8,3 секунды) также включает в себя большие затраты на «инициализацию» виртуальной машины Java – загрузку и инициализацию всех требуемых классов и достижение устойчивого состояния JIT (Just-In-Time – системы оперативной поставки узлов) компилятора Java. Реальная таблица стилей выполняет четыре или пять проходов по исходному документу (один для отображения основного текста, дополнительные проходы для создания оглавления, глоссария и различных приложений), а также много раз получает доступ по ключу для создания развернутых перекрестных связей в форме гиперссылок. Поэтому поразительно то, что затраты времени на анализ исходного документа и построение структуры его дерева почти столь же велики, как и затраты на само преобразование.
Приведение в последовательную форму:670 мс
Компиляция:
Для контраста на рисунке 3. 2 показано преобразование, которое более типично для преобразования XML в HTML «по требованию», выполняющееся на веб-сайтах, где данные хранятся в XML и отображаются каждый раз, когда их содержание затребовано пользователем. В этом примере используется та же самая таблица стилей; единственное отличие в том, что исходный документ намного меньше по объему – на этот раз всего 8 Кб. Это уменьшает полное время преобразования до 1,6 секунды, из которых 79 процентов времени тратится на компиляцию таблицы стилей. Очевидным следствием этого факта является необходимость выполнения компиляции таблицы стилей только один раз с последующим многократным ее применением при таком сценарии использования.
Другой интересный факт заключается в том, что, хотя таблица стилей является той же самой, как и в примере, показанном на рисунке 3.1, отношение времени преобразования времени, затраченному на анализ и создание дерева, в этом случае намного выше. Вероятным объяснением этого факта будет то, что стадия создания дерева ответственна за запрос всей памяти, используемой для преобразования, и затраты на выделение требуемой памяти увеличиваются более чем линейно в зависимости от размера исходного документа, так как на это влияет страничная организация памяти или ее фрагментации. Также может иметь место тот факт, что стадия преобразования включает в себя затраты времени на запуск, которая не зависит от размера документа.
Приведение в последовательную форму: 50 мс
Какие последствия все это имеет для XQuery? Многие системы XQuery будут работать с базами данных, в которых данные предварительно загружены в структуру базы. Структура базы данных выполняет ту же роль, как и расположенное в памяти дерево, используемое процессорами XSLT, но эта структура создается только однажды, когда документ загружается или заменяется в базе данных, а не при выполнении каждого запроса. При этом не подразумевается, что время, затраченное на создание дерева, может игнорироваться – наоборот, время, расходуемое на загрузку и обновление данных, всегда было критическим фактором для баз данных, поддерживающих эффективные иерархические пути доступа, и этот факт можно легко забыть после двадцати лет доминирования реляционных баз данных с их плоской структурой хранения. Системы XQuery должны пойти на точно такой же компромисс, как и процессоры XSLT, между временем, затрачиваемым на создание и индексирование дерева и скоростью путей доступа, обеспечиваемых деревом, как только оно было создано. Во многих случаях им придется принимать более трудные решения, потому что процессор XSLT может создать дерево со знанием того, какое преобразование будет иметь место, тогда как деревья, созданные процессором XQuery, должны будут поддерживать множество различных видов запросов.
Наблюдения, касающиеся времени компиляции, также относятся к процессору запросов. Хотя запросы объемом 1000 строк вероятно будут менее обычными, чем таблицы стилей объемом 1000 строк, тем не менее будут существовать сложные запросы, и сложность их компиляции, вероятно, будет пропорционально больше, чем для таблиц стилей XSLT из-за критической важности нахождения оптимального пути доступа к данным, когда происходит обработка источников данных объемом в несколько гигабайт, а не просто несколько килобайт. Но как и в случае с XSLT, будут иметь место одноразовые запросы, для которых не будет никакой выгоды от многократного использования скомпилированного запроса, и будут запросы, где такое использование существенно.
Рассмотрев фактическое время выполнения запроса или преобразования в некоторой перспективе, мы теперь обратимся к различным методам оптимизации, которые могут быть использованы для увеличения производительности.
