Would building a key be faster?
Probably difficult to maintain while editing?
A. Pierrot
i2S/APSED
Le 4 nov. 08 ? 19:04, Hussein Shafie a ?crit :
>
> Trevor Nash wrote:
>>
>> Hussein Shafie wrote:
>> The performance problem comes from the "id()" XPath function. There
>> is
>> simply no way to make this kind of rule fast in the context on an XML
>> editor (while this is not a problem for a browser or for an XSLT
>> processor).
>>
>> I'm not sure why you say that. XSLT processors and the like will
>> build
>> an index on reading the document - if they are really smart they
>> delay
>> this until the first id() function is executed. I imagine you know
>> this
>> already.
>>
>
> XMLmind XML Editor does exactly that too: lazy computation of a
> id->Element map. The slow performance comes from the fact that, when
> used by the CSS engine, the id->Element map is forgotten just after it
> has been computed.
>
> In fact, the XPath 1.0 implementation of XMLmind XML Editor (which is
> very fast and very reliable because it comes from James Clark's XT)
> has
> not been designed to be primarily used by the CSS engine, but more by
> macro-commands, configuration files, etc.
>
>
>
>
>> The difference in an editing environment is that you have to maintain
>> the index as the document changes. This is certainly technically
>> feasible, though the cost is dependant on the architecture of the
>> editor
>> and its data store, and it may not be worth the effort for the
>> number of
>> times it is used.
>>
>
> Yes, this is feasible, but clearly not worth the effort in the context
> of XMLmind XML Editor's CSS engine.
>
>
>
>> BTW your workaround is unlikely to be faster because it is still
>> examining every node in the tree, but matching the element name
>> instead
>> of looking at the id value - then when it matches it looks at the id
>> value as well. You only get an advantage if you know something like
>> what level the element is in the tree, e.g. if you are looking for
>> a top
>> level section then /*/*...@id...] might work. The killer is the //
>> at the
>> beginning of the xpath.
>>
>
> Yes, anything more specific than //xxx (like /*/*...@id...]) would be
> faster.
>
>
>
>> Essentially id('x') is the same as //*...@id='x']
>>
>
> * id() queries the schema to find the type of each attribute of an
> element. This makes it potentially slower than //*...@id='x'].
>
> * //*...@id='x'] could be faster if it had not to traverse the whole
> document tree. How to make //*...@id='x'] stop its traversal after it
> finds the first matching element? //*...@id='x'][1]? I'm not sure.
>
>
>
> --
> XMLmind XML Editor Support List
> xmleditor-support at xmlmind.com
> http://www.xmlmind.com/mailman/listinfo/xmleditor-support
> ---------------------------------------------------------------------------------------
> Orange vous informe que cet e-mail a ete controle par l'anti-virus
> mail.
> Aucun virus connu a ce jour par nos services n'a ete detecte.
>
>
