Hi Gareth.
I don't provide you any example just because what I'm saying is evident from
the Xerces code.
There's a global list instead of something local to the node. And, probably,
the list is too small for handling data associated to each node.
After writing this email, I changed the implementation of the DOMNodeImpl
class, adding a pointer that is going to be used in case the
get/setuserData() is invoked on this node.
I know that this is not a clean implementation (since this pointer supports
only ONE associated data, while the set/getUserData() are able to associate
more data through a key), but these are the results of my application:
- xerces 2.4.0 (Win32): 11 sec
- xerces 2.6.0 (Win32): 36 sec
- xerces 2.6.0 (Win32) + my patch: 3.5 sec
In my case, the overhead of the setUserData() is not important since I call
this function only a few times; however, it is very imporant the overhead of
the getUserData() which gets called > 1M times during the execution.
If you want, I can test a possible patch for Xerces (Win32) without any
problem (instead, it is pretty difficult to send my code to you, since it
has several dependencies).
For instance, if having a pointer associated to each node may be an
unacceptable overhead (as Alberto said in another reply), it may be very
helpful to have a function that is able to change the size of the hash (if
it exists, sorry then, I wasn't able to locate it).
Thanks for your time,
fulvio
===================================================================
Date: Mon, 17 Jan 2005 15:48:52 +0000
From: Gareth Reakes <[EMAIL PROTECTED]>
Subject: Performance issues in DOMNode::setUserData() /
DOMNode::getUserData()
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi,
Fulvio Risso wrote:
> However, from an architecture point of view, I believe data should be
> attached to every single node instead of using a global list.
I don't recall why it was done this way, does anybody else? It was like
that when I first started using xerces. I would assume it would be to
keep the DOM nodes smaller. This is a not a frequently used feature.
>
> Does anyone has any suggestion in order to avoid such this problem?
Is the slow down from accessing or putting them in? You could try and
make the hash modulus bigger. Alby put a optimization in a while ago for
this stuff. I have had a chat with him and he says he has another
possible optimization. Could you provide us with the test case and use
case for it (if the docs are large then send them off list).
Cheers,
Gareth
--
Gareth Reakes, Managing Director Parthenon Computing
+44-1865-811184 http://www.parthcomp.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
