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

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

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!


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]