This would require that we reference-count our implementation, which would
result in drastically reduced performance for the cases where the tree are
not so large. The earliest versions of Xalan were reference-counted, and
built on top of the Xerces DOM smart-pointers, and the performance cost was
significant. In many cases, we would spend 30% of the time just managing
reference counts, and copy-constructing and destructing the smart-pointers.
Smart-pointers are great for some things (some objects in Xalan-C++ _are_
reference-counted), but maintaining reference counts on a "tree" which is
accessed constantly and in a potentially random manner is something totally
different.
You can always build an implementation on top of our abstract base classes
which creates nodes on demand, which would require a much smaller memory
footprint for each node. That's about the best you can do, and until we
have XSLT processors which know how to prune parts of the tree that are no
longer needed, we'll always potentially need access to the full tree.
On the other hand, Xalan is open-source, so you're free to take the
processor as-is and implement reference-counting for the source tree. If
you can prove that the overhead of such an implementation can be held to
2-3% of the total processing cycles, then we'll consider working in your
changes.
Dave
|---------+--------------------------->
| | "Vitaly |
| | Korovinsky" |
| | <vitalyk@sympati|
| | co.ca> |
| | |
| | 04/15/2002 02:48|
| | PM |
| | Please respond |
| | to xalan-dev |
| | |
|---------+--------------------------->
>---------------------------------------------------------------------------------------------------------------------------|
|
|
| To: <[EMAIL PROTECTED]>
|
| cc: (bcc: David N Bertoni/Cambridge/IBM)
|
| Subject: Re: Using Xalan in a database environment
|
>---------------------------------------------------------------------------------------------------------------------------|
The previous post refers to C++ processor. Sorry I didn't notice that the
maillist is shared by both C++ and Java projects. In Java such problem
doesn't exist due to automatic garbage collection. An implementation of
interface org.w3c.dom.Node can create new isntances of the class which will
be later reclaimed by GC. In C++ however instances allocated on heap should
be explicitly deleted. In my case the sooner I free the memory the better,
in other words I wouldn't want to wait for the end of transformation to
delete all the objects that were created along the way. The best policy
would be to keep only the objects that are currently being used by XSLT
transformer.
Thanks
