[xslt] 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]