My two cents (maybe a bit less). Would it not make more sense to focus on
deallocation first instead of trying to make the implementation more
compact? Especially since you had mentioned that there may be an expense in
execution speed for a more compact implementation, there is a known
limitation on the number of nodes, and you (and I) desire to support
deallocation.
FWIW, I had hoped to be able to devote some time to the deallocation issue -
but I do not see that happening in the near future.
Art
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Saturday, July 07, 2001 3:21 PM
To: [EMAIL PROTECTED]
Subject: RE: Xalan 2.2.0D6 has great performance gain!
...
Note that the actual size of a tree using the current SAX2DTM is not that
much smaller that the older Stree implementation. However, we are working
on a more compact implementation, though it may be at some expense to
execution speed.
The downsides of DTM:
1) Our implementation requires what is essentially internal heap
management. For instance, de-allocation of subtrees if you know you are
done with them, which we have long wanted to do, becomes much more
complicated. Also, because growing the arrays is quite an issue, we use
the SuballocatedIntVector object instead of a straight int array.
2) Limits of tree size. Currently a DTM tree is limited to 1,048,575 nodes,
and the number of trees you can have per manager is 4095. This is because
the node handle carries both node identity and tree identity.
...
So, you can see, it is a bit of a mixed bag. I would like to say it is the
perfect solution, but it isn't. On the other hand, it seems to be so far
an overall win. My biggest worry right now is what we're going to do about
subtree deallocation (and reuse) when the time comes.
...
-scott
...
