Hi Thomas, 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)
On most of the files it works fine, all DOM nodes are deleted, text, paths, ... 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. 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, >> >> 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. > > It sounds like something funny is going on here. As long as you > 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]
