2013-09-24 3 views
2

У меня есть документ XML в следующем формате:быстрое выражение XPath для XSL: стоимость из

<Contents> 
    <Content Name="ClientXML"> 
    <EntityData> 
     <Data Name="EQ_EligibleForGuaranteedIssue">Yes</Data> 
     <Data Name="ABRInd">NO</Data> 
     <Data Name="AC_AgentNo">12345</Data> 
     <Data Name="AC_AgentPersonallyMetWithApplicant">Has</Data> 
     <Data Name="AC_City">Pomona</Data> 
     <Data Name="AC_FirstName">Kimmy</Data> 
     <Data Name="AC_FullName">Kimmy N Jackson</Data> 
     <Data Name="AC_Initials">K J</Data> 
     <Data Name="AC_LastAndSuf">Jackson</Data> 
     ... 
    </EntityData> 
    </Content> 
    <Content Name="UserXML"> 
    <EntityData> 
     <Data Name="TransRefGUID">789-456-123456789-456</Data> 
     ... 
    </EntityData> 
    </Content> 
</Contents> 

Другая информация:

  1. Там может быть несколько тысяч узлов «данные» под каждым " Объект EntityData
  2. Значение любого атрибута «Имя» никогда не дублируется.

Мне нужно создать преобразование XSL и использовать функцию xsl: значение select = "...". Мой вопрос: какое выражение XPath будет выполнять быстрее всего? Например

<xsl:value-of select="\\Contents\Content[@Name="ClientXML"\EntityData\Data[@Name=".."]"> 

или просто

<xsl:value-of select="\\Data[@Name=".."]"> 

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

Удивление, если у кого-то есть мнение, и в гораздо большем масштабе, если человек может быть быстрее.

Спасибо!

ответ

3

Использование ключей в XSLT будет намного быстрее, чем выражение XPath, особенно одно с //, которое может быть очень медленным для выполнения и должно использоваться только при необходимости.

<xsl:key match="Content" use="@Name" name="MyContentsLookup"/> 
... 
<xsl:value-of select="key('MyContentsLookup','ClientXML')"/> 

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

Я опубликовал обзор XSLT ключей здесь: http://www.CraneSoftwrights.com/resources/xslkeys/index.htm

+0

Этот ответ действительно самый быстрый. Однако, если есть ситуация, когда вы используете значение функции select = xsl, я смог выполнить тест: Полный путь:/Содержание/Контент [@ Name = 'ClientXML']/EntityData/Data [@ Name = $ name] был намного быстрее, чем короткий путь: // Данные [@ Name = $ name] –

+0

Точно. Это была моя точка зрения. '//' может быть очень медленным. Это связано с тем, что вы просите процессор выглядеть абсолютно повсюду в вашем документе для обрабатываемого элемента, и процессор не знает останавливаться, когда находит именно тот, который вы ищете. Принимая во внимание, что когда вы укажете полный адрес XPath, процессор не ищет ненужного места в другом месте. Таким образом, ваше более длинное выражение выполняется быстрее.И, в конце концов, мы должны взять дополнительное время, чтобы сделать наш код быстрым, а не использовать ярлыки ненужно. –

0

Когда вы говорите, содержание Имя никогда не дублируется, является то, что верно по документу в целом, или только в пределах каждого элемента контента? Если это правда глобально, то техника Кена, использующая ключи, идеальна. Если это правда только локально, вам может потребоваться настроить ключ, который объединяет Content/@ Name с EntityData/@ Name.

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

Смежные вопросы