[xslt] Re: [xml] Re: libxslt effects on _private member of libxml structures
- From: Daniel Veillard <veillard redhat com>
- To: Luca Padovani <lpadovan cs unibo it>
- Cc: "xslt gnome org" <xslt gnome org>, xml gnome org
- Subject: [xslt] Re: [xml] Re: libxslt effects on _private member of libxml structures
- Date: Wed, 26 Mar 2003 05:15:54 -0500
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]