Re: [xml] Re: libxslt effects on _private member of libxml structures



On Wed, Mar 26, 2003 at 10:58:30AM +0100, Luca Padovani wrote:
Hi,

the mechanism suggested by Steve can be generalized further and in fact
DOM Level 3 (which is still a working draft) provides for it. You can
attach arbitrary objects to a DOM node, each object being associated to
a key. Different applications wishing to attach data to the same node
are supposed to use different keys. This would be of course slower than
array access, but in my experience I never had strict time constraints
on the extra-data.

  Okay, interesting, if we end up standardizing _private access then
trying to follow this API makes sense to me.

The other possibility (with the hash-table) doesn't seem to me _that_
bad, assuming the associated data is sparse. Being the key the pointer
to the libxml2 node, the hash function would be very quick.

  Except hash tables operate on strings, and converting an address to
a string take some processing, and again computing the function hash
on the string is yet more CPU cycles.

On Wed, 2003-03-26 at 10:39, Sean McGuire wrote:
comments currently state it is, and add another field for holding the 
key() value for libxslt.

I fear this would break binary compatibility, and would make every node
slightly larger (aren't they too large already?)

  Right, the current libxml2 representation is already huge compared
to XSLT needs...

  I'd prefer this, one reason being that it 
limits the changes to libxslt, rather than everyone who has used the 
_private field for their own application-specific data.

  agreed,

BTW, I'm still not totally convinced that XSLT key()'s cannot be
implemented efficiently otherwise, but of course I have to look at
Daniel's code before commenting on this further. Does anybody else share
my suspect or you all agree there's no other way of doing it?

  One thing I could do is save the _private before processing if needed
and restore them after processing. This would restrict the costs only
to stylesheets using keys and only when _private was already in use.
But I need to think more about this before trying to make some changes.

Daniel


-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/



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