Re: [xml] Length xmlTextReaderConst... contents?

[Ralf Junker <ralfjunker gmx de>]

At 15:05 11.04.2008, Daniel Veillard wrote:

>  actually no, the parser computed the lenght at some point for example
>when interning the string.

Thanks for clearing this up. I was under the impression that I must have missed something obvious.

>  Have you actually tried to do a fine grained analysis, i really doubt
>the strlen is taking any noticeable time compared to any useful processing
>on top... beware of unchecked performance opinion :-)

I hav to strlen() through 12 GB of data in total, so it is bound to take up some time, but probably not as much as to make it really slow.

>> Hmm...  What about following idea:
>> 
>> You may try to cache length of strings.
>> Const family of functions returns pointer to the "interned" string
>> from the internal Reader dictionary.  It relates to node and attribute
>> names.
>> 
>> You may prefill it with strings need for- or expected by you using
>> xmlTextReaderConstString().  In the same time you can calculate
>> strlen() and fill both (pointer to the interned string and its length)
>> into e.g. array.
>> 
>> After that you can both save time by eliminating strcmp() and using
>> direct pointer comparison, and avoid strlen() calls using lookup
>> inside this prefilled array.
>> 
>> If lookup fails (unknown node or attribute), then you may fallback to
>> the "usual" strlen() or just ignore unknown element depending of logic
>> of your application.
>
>  Hum, most compilers optimize strlen() very well, your solution may actually
>be more expensive than the speudo call as soon as your array includes more
>than a dozen entry which sounds like a very short vocabulary.
>  But yes this should return the interned strings,

Thanks, I will look into this!

Ralf