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