Hi Gareth,
Thanks for the clarification.
Still have a few more things to clarify.
1. Is the problem relating to releasing attributes limited to ID
attributes because thats what bugzilla says or this
problem will occur with any type of attribute.
2. Is there any writeup on how much memory each of the DOM classes
take. Assuming the element names are string pooled(not counting the string
pool itself). I looked up some info on CVS which said DOMElementImpl took 48
bytes.
I wanted to store some extra data(DOMUserData) and the price for
this is very heavy since it creates a RefHashTableOf of size 29. So my
memory requirement shot up almost 400 bytes for every DOMElementImpl.
Is there any way, these sizes in these DOM structures can be
configurable. Xerces seems to use some default size and most of it maybe
unused. Is it not wise to configure these in the DOMBuilder somehow.
3. Are there any efforts made at allowing spooling to disk or
allowing for a interface to do so. XML files are growing in size and xerces
is making a good effort at controlling element and attribute names but not
so with the data(DOMCharacterDataImpl).
Thanks
Kiran
-----Original Message-----
From: Gareth Reakes [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, November 20, 2002 2:54 AM
To: '[EMAIL PROTECTED]'
Subject: RE: Memory growth in DOM
Hi Kiran,
perhaps we are using different terminology here and confusing each
other. I will attempt to explain my understanding.
i) Things like element and attribute names are stored in a memory block
and are acquired by calling getPooledString. These are strings managed by
the document and will only be deleted when the document is. The same
technique is used when you call getValue on an attribute. Also, if that
string already exists in the pool, a new one is not created (i.e. if two
attributes have the same name, their names will share the same string in
the string pool.)
ii) DOMAttrImpl and DOMElementImpl (as well as the other node types) are
also stored in memory managed by the document. When you call one of the
factory methods, such as createElement, the document uses 'placement new'
to allocate the memory. Consider element creation: If someone has released
an element before we call create, then our new element will reuse this
memory as opposed to using a block of memory that has not previously been
used, or even creating a new block if we have run out of space.
iii) The document manages some memory that is newed by the creation and
use of nodes (such as DOMAttrMapImpl in the constructor of
DOMElementImpl). However, in the same way as the names of attributes and
elements, calling release on the element will not delete these things --
only releasing the document will do this. This is why you will see memory
increasing by simply creating and deleting elements of the same name.
There is also an issue with releasing elements that contain attributes:
The attibutes do not currently get released and there is no way to do so
after the release of the element (though it will be released with the
release of the document - see Bug[13197]).
I hope this makes it clearer! If not please point out where as I intend
to archive this message because I feel that it will be asked again!
Gareth
--
Gareth Reakes, Head of Product Development
DecisionSoft Ltd. http://www.decisionsoft.com
Office: +44 (0) 1865 203192
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
