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]
