Harm Cuppens wrote:
Hi Thomas,I think you might have miss understood. when I say 'text node" I mean
The file exists only out of path elements and a title and desc element (with <svg> as the parent). I've tested my deletion routine (which keeps the <defs> section so that other elements can reference those if they are present in the file)
node.getNodeType() == TEXT_NODE not Element nodes with the tag 'text' (that have text
nodes as children in order to be useful). The GVT builder just skips these and only looks at
the Element nodes.
On most of the files it works fine, all DOM nodes are deleted, text, paths,Until the patches I committed last night the were certainly not getting GC'ed. I believe that with
... But I can't tell if they are being GC'ed. I have a feeling they are not.
When I watch the DOM viewer in Squiggle, my documents will only contain the
SVG element and the defs section. But looking at the memory monitor shows no
real memory gain by deleting the dom nodes (I expected to see a noticable
difference or does the DOM not occupy a lot of memory?) so I don't think
they get GC'ed.
the current CVS they will get GC'ed. If you get current CVS and you suspect they are not
getting GC'ed the class batik.util.CleanerThread can be easily used to trace when/if objects are
GC'ed (create a small subclass of CleanerThread.SoftReferenceCleared that prints something when
it's 'cleared' method is called (you might want to ferret away object.toString() on construction)).
Please do and report back if possible.Another thing that makes me believe they're not GC'ed is the fact that my big document still generates the OutOfMemory error. I log all the nodes being deleted from the document and apparently all 45.000 nodes are being deleted (text nodes included) which doesn't mean they get GC'ed of course.
I'll get your updates from CVS as soon as they become available and give it
another go.
Thanks for the help!
-----Original Message-----
From: Thomas DeWeese [mailto:[EMAIL PROTECTED] Sent: maandag 7 juli 2003 21:02
To: [EMAIL PROTECTED]
Subject: Re: Out of memory loading big document
Thomas DeWeese wrote:
Harm Cuppens wrote:
Hi all,It sounds like something funny is going on here. As long as you
I'm experiencing java.lang.OutOfMemoryError when trying to load a big svg file (a whopping 5.35MB). I have the latest CVS version of Batik.
The document i'm loading is static, so I've been trying to delete the dom elements as soon as they have been converted to their corresponding gvt equivalents (in GVTBuilder) in the hope to free up some memory. Unfortunately I haven't been successful to get rid of the outofmemory error. This process is also terribly slow because each removal of a node checks if the node is a child of the parent we wish to remove it from and the parent contains 40.000 nodes. But that is not batik's fault but the way DOM works.
are deleting nodes from
start to finish the removal time should be quite good. You might want to check that you delete
TextNodes between the elements (I'm guessing that you have an equal number of Element nodes
and Text nodes in the DOM as generally your element nodes have whitespace between them
(like a newline + indenting) - if you don't remove these as well as the real elements it could
get slow to find the last few elements. Also this should help memory use quite a bit.
Can you tell if the nodes you are removing are getting GC'd?
What are the nodes, shapes, text, use?
Using the new Memory Leak tests, I have verified a huge memory leak that prevented any
DOM node from going to GC if it was read from a stream (as opposed to nodes created
through script). This is now fixed and the change will be committed later tonight.
The comments on removing TextNodes still stands.
--------------------------------------------------------------------- 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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
