You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-users@xmlgraphics.apache.org by th...@kodak.com on 2009/10/13 11:48:18 UTC
Re: BATIK Memory consumption is too high
Hi Kurram,
Khurram Zaman <Kh...@sensys.com> wrote on 10/12/2009 02:45:38 AM:
> We are using BATIK for rendering SVG in java applets. Our SVGs are
> of pretty big size (in MB's). This SVG gets animated as well. We
> need to unload and load different SVGs.
> What are the possible techniques to solve this?
Yes, possibly, some aspects of SVG are more memory intensive
than others. What sort of SVG files are you working with (what
features are you using).
> Can any flags help?
Well, I think you can raise the default partition for Java
Applets. You might look at that.
> Can I optimize the BATIK memory usage through its code?
Only if you want to rewrite large parts of the code base...
> Also is BATIK not feasible for big SVGs?
The default partition for Java is something like 32-64MB of
memory - this is barely enough memory to decode your typical 10MP
JPEG. The packing factor for SVG is typically much higher. So
I would suggest looking for ways to increase the default memory
partition of the Java Virtual Machine.
Re: BATIK Memory consumption is too high
Posted by th...@kodak.com.
Hi Praveen,
Praveen Nayak2 <pr...@in.ibm.com> wrote on 10/13/2009 02:13:23 PM:
> This file uses up near 100 MB of memory causing Java plugin to
> croak, unless we tinker with the memory limit. Like Khurram I wonder
> if I can reduce the memory footprint...
I am not aware of any easy steps that could be taken to
reduce the memory footprint. That doesn't meant that there
aren't any, but right now I don't know of any area where we
hold multiple copies of data without an architectural reason
(like we need the string version of 'd' for DOM, but we have
a 'general path' version for rendering).
Re: BATIK Memory consumption is too high
Posted by th...@kodak.com.
Hi Zaman,
Khurram Zaman <Kh...@sensys.com> wrote on 10/20/2009 02:30:12 AM:
> I am attching two snaps taken after prifiling the memory. They
> mention some objects which are not de-allocated. The objects which
> have positive difference are leaked.
So I'm not sure the graphs are telling you what you think
they are telling you (or perhaps I misunderstand the tool). Since
Java uses Garbage collection all the 'positive difference' tells
you is that new objects were allocated, and the old objects haven't
been GC'ed yet.
In the case of the GVTGlyphMetrics this is expected, even the
number allocated is about what I would expect since it roughly
doubled the number of instances, which would simply indicate
that essentially all of the characters in the SVG changed.
Finding memory leaks in Java usually requires making the
problem clear through this 'noise'. Typically this requires
causing the leaking event occur many, many times. Then checking
object counts and notice objects that have 'accumulated' extra
instances, then when these 'bad' instances out number the
good instances you can start looking at the reference
chains to figure out what is keeping the bad instances live.
Re: BATIK Memory consumption is too high
Posted by Khurram Zaman <Kh...@sensys.com>.
Hi Thomas,
Your response on setting display to none has been useful and we have
reduced teh size of SVG to reduce the memory footprint.
> Do you know what objects aren't getting de-allocated? In the
> past our memory leaks have almost always had to do with adding/removing
> elements from the Document - which you don't mention doing.
I am attching two snaps taken after prifiling the memory. They mention
some objects which are not de-allocated. The objects which have positive
difference are leaked.
Regards,
Khurram.
thomas.deweese@kodak.com
10/15/2009 04:09 PM
Please respond to
batik-users@xmlgraphics.apache.org
To
batik-users@xmlgraphics.apache.org
cc
batik-users@xmlgraphics.apache.org
Subject
Re: BATIK Memory consumption is too high
Hi Khurram,
Khurram Zaman <Kh...@sensys.com> wrote on 10/14/2009 07:22:08 AM:
> I would like to show you a sample SVG which is loaded by our software.
I see this a lot in your document:
<clipPath id="clip_text1100">
<text y="349" x="256"
transform="matrix(1.0 0.0 0.0 1.0 467.1178 -254.12196)"
style="fill:#000000;stroke:black;stroke-width:0;font-family:Verdana;font-weight:normal;font-style:normal;font-size:12;shape-rendering:crispEdges;stroke-dasharray:0,
0;"
startOffset="0" prevfill="#000000" changeflag="true">
##
</text>
</clipPath>
<text y="349" x="256"
style="fill:#000000;stroke:black;stroke-width:0;font-family:Verdana;font-weight:normal;font-style:normal;font-size:12;shape-rendering:crispEdges;stroke-dasharray:0,
0;"
startOffset="0" prevfill="#000000" id="bg"
changeflag="true">
##
</text>
<rect y="86.15416" x="723.1178" width="17.35638427734375"
transform="matrix(1.0 0.0 0.0 1.0 -467.1178 254.12196)"
style="fill:black;stroke:none;visibility:hidden;" id="fg"
height="8.723876953125" clip-path="url(#clip_text1100)"/>
Which seems like you have at least two copies of the geometry.
Also using a clip-path is perhaps one of the more expensive way to
draw text.
> Is there any way that I can remove the creation of objects which
> are not to be used by us. Also if this is so then what is the best
> way to go about it. How should I identify what objects are being
> created and not being used and how can I remove their creation?
So you can set the display property to 'none' which will prevent
Batik from creating graphics nodes. You can also remove elements
from the DOM tree, which will prevent Batik from needing to handle
CSS for those elements.
> I would also like to tell you how we are using transformations. Our
> application in real time and we have values coming every second. We
> animate the SVG according to those values per second (or even faster
> if the values come faster). When we do so, the memory consumption
> keeps rising and the objects dont get de-allocated.
Do you know what objects aren't getting de-allocated? In the
past our memory leaks have almost always had to do with adding/removing
elements from the Document - which you don't mention doing.
> How can I reduce the objects being created in batik.
For the things you mention we shouldn't be creating very many
graphics node objects for the types of changes you list.
> Usually when the values come we perform setProperty on style attributes
of
> repestive shapes. We usually scale the objects, translate them or
> rotate them depending on the value by setting the transform property.
> We set visibility through setproperty.
If you don't need hidden elements to receive events you can
set display to none (through setProperty).
> We also have event listeners attached to the elements of SVG.
Event listeners can cause memory leaks.
> I have set a maximum heap size of 800Mb (which is huge). And our
> application is expected to run for months. An urgent response would
> be really helpful since memory stabilization is very important to
> us. I also wanted to ask you about SVG Salamader and if you have any
> reservations about that library over batik?
I don't know anything about SVG Salamander.
Re: BATIK Memory consumption is too high
Posted by th...@kodak.com.
Hi Khurram,
Khurram Zaman <Kh...@sensys.com> wrote on 10/14/2009 07:22:08 AM:
> I would like to show you a sample SVG which is loaded by our software.
I see this a lot in your document:
<clipPath id="clip_text1100">
<text y="349" x="256"
transform="matrix(1.0 0.0 0.0 1.0 467.1178 -254.12196)"
style="fill:#000000;stroke:black;stroke-width:0;font-family:Verdana;font-weight:normal;font-style:normal;font-size:12;shape-rendering:crispEdges;stroke-dasharray:0,
0;"
startOffset="0" prevfill="#000000" changeflag="true">
##
</text>
</clipPath>
<text y="349" x="256"
style="fill:#000000;stroke:black;stroke-width:0;font-family:Verdana;font-weight:normal;font-style:normal;font-size:12;shape-rendering:crispEdges;stroke-dasharray:0,
0;"
startOffset="0" prevfill="#000000" id="bg"
changeflag="true">
##
</text>
<rect y="86.15416" x="723.1178" width="17.35638427734375"
transform="matrix(1.0 0.0 0.0 1.0 -467.1178 254.12196)"
style="fill:black;stroke:none;visibility:hidden;" id="fg"
height="8.723876953125" clip-path="url(#clip_text1100)"/>
Which seems like you have at least two copies of the geometry.
Also using a clip-path is perhaps one of the more expensive way to
draw text.
> Is there any way that I can remove the creation of objects which
> are not to be used by us. Also if this is so then what is the best
> way to go about it. How should I identify what objects are being
> created and not being used and how can I remove their creation?
So you can set the display property to 'none' which will prevent
Batik from creating graphics nodes. You can also remove elements
from the DOM tree, which will prevent Batik from needing to handle
CSS for those elements.
> I would also like to tell you how we are using transformations. Our
> application in real time and we have values coming every second. We
> animate the SVG according to those values per second (or even faster
> if the values come faster). When we do so, the memory consumption
> keeps rising and the objects dont get de-allocated.
Do you know what objects aren't getting de-allocated? In the
past our memory leaks have almost always had to do with adding/removing
elements from the Document - which you don't mention doing.
> How can I reduce the objects being created in batik.
For the things you mention we shouldn't be creating very many
graphics node objects for the types of changes you list.
> Usually when the values come we perform setProperty on style attributes
of
> repestive shapes. We usually scale the objects, translate them or
> rotate them depending on the value by setting the transform property.
> We set visibility through setproperty.
If you don't need hidden elements to receive events you can
set display to none (through setProperty).
> We also have event listeners attached to the elements of SVG.
Event listeners can cause memory leaks.
> I have set a maximum heap size of 800Mb (which is huge). And our
> application is expected to run for months. An urgent response would
> be really helpful since memory stabilization is very important to
> us. I also wanted to ask you about SVG Salamader and if you have any
> reservations about that library over batik?
I don't know anything about SVG Salamander.
Re: BATIK Memory consumption is too high
Posted by Joel Uckelman <uc...@nomic.net>.
Thus spake Praveen Nayak2:
>
> This file uses up near 100 MB of memory causing Java plugin to croak,
> unless we tinker with the memory limit. Like Khurram I wonder if I can
> reduce the memory footprint...
>
You should look at your program in a profiler to see how that memory is
being used. I'm going to take a wild guess and say that a substantial
portion of your memory usage is due to having a very large BufferedImage
to which you're rendering. (This is the case for an app I work on.) If
that turns out to be the situation you have, and you're usually displaying
only a portion of the image at any one time, a possible solution is to render
the SVG as small tiles, for which you keep SoftReferences. That way, when
memory gets tight, some of the tiles will be garbage collected and will have
to be rendered again later, but you won't have the cost of having a gigantic
BufferedImage in memory.
--
J.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: BATIK Memory consumption is too high
Posted by Praveen Nayak2 <pr...@in.ibm.com>.
Hi Thomas,
I have the same problem as Khurram, except for the animation as I don't
use any.
An example SVG file of mine would be ~4 MB in size
A total of a little over 11,000 elements.
Most of the tags are one of "a, desc, ellipse, g, image, line,
path, polygon, polyline, rect, set, style, text, title".
Some tags like style have < 10 entries. Others like line, polygon
> 1000 instances. But then again, this is just an example.
This file uses up near 100 MB of memory causing Java plugin to croak,
unless we tinker with the memory limit. Like Khurram I wonder if I can
reduce the memory footprint...
Thanks,
Praveen
thomas.deweese@kodak.com
13/10/2009 03:18 PM
Please respond to
batik-users@xmlgraphics.apache.org
To
batik-users@xmlgraphics.apache.org
cc
batik-users@xmlgraphics.apache.org
Subject
Re: BATIK Memory consumption is too high
Hi Kurram,
Khurram Zaman <Kh...@sensys.com> wrote on 10/12/2009 02:45:38 AM:
> We are using BATIK for rendering SVG in java applets. Our SVGs are
> of pretty big size (in MB's). This SVG gets animated as well. We
> need to unload and load different SVGs.
> What are the possible techniques to solve this?
Yes, possibly, some aspects of SVG are more memory intensive
than others. What sort of SVG files are you working with (what
features are you using).
> Can any flags help?
Well, I think you can raise the default partition for Java
Applets. You might look at that.
> Can I optimize the BATIK memory usage through its code?
Only if you want to rewrite large parts of the code base...
> Also is BATIK not feasible for big SVGs?
The default partition for Java is something like 32-64MB of
memory - this is barely enough memory to decode your typical 10MP
JPEG. The packing factor for SVG is typically much higher. So
I would suggest looking for ways to increase the default memory
partition of the Java Virtual Machine.
Re: BATIK Memory consumption is too high
Posted by Khurram Zaman <Kh...@sensys.com>.
Hi thomas,
I would like to show you a sample SVG which is loaded by our software.
I want to ask if there is any way that I can reduce the memory footprint
of the SVG. I am sure that there would be a lot of things which we are not
using related to SVG. Is there any way that I can remove the creation of
objects which are not to be used by us. Also if this is so then what is
the best way to go about it. How should I identify what objects are being
created and not being used and how can I remove their creation?
I would also like to tell you how we are using transformations. Our
application in real time and we have values coming every second. We
animate the SVG according to those values per second (or even faster if
the values come faster). When we do so, the memory consumption keeps
rising and the objects dont get de-allocated. How can I reduce the objects
being created in batik. Usually when the values come we perform
setProperty on style attributes of repestive shapes. We usually scale the
objects, translate them or rotate them depending on the value by setting
the transform property. We set visibility through setproperty.
We also have event listeners attached to the elements of SVG.
I have set a maximum heap size of 800Mb (which is huge). And our
application is expected to run for months. An urgent response would be
really helpful since memory stabilization is very important to us. I also
wanted to ask you about SVG Salamader and if you have any reservations
about that library over batik?
Regards,
Khurram
Project Manager
Visualization team.
thomas.deweese@kodak.com
10/13/2009 03:48 PM
Please respond to
batik-users@xmlgraphics.apache.org
To
batik-users@xmlgraphics.apache.org
cc
batik-users@xmlgraphics.apache.org
Subject
Re: BATIK Memory consumption is too high
Hi Kurram,
Khurram Zaman <Kh...@sensys.com> wrote on 10/12/2009 02:45:38 AM:
> We are using BATIK for rendering SVG in java applets. Our SVGs are
> of pretty big size (in MB's). This SVG gets animated as well. We
> need to unload and load different SVGs.
> What are the possible techniques to solve this?
Yes, possibly, some aspects of SVG are more memory intensive
than others. What sort of SVG files are you working with (what
features are you using).
> Can any flags help?
Well, I think you can raise the default partition for Java
Applets. You might look at that.
> Can I optimize the BATIK memory usage through its code?
Only if you want to rewrite large parts of the code base...
> Also is BATIK not feasible for big SVGs?
The default partition for Java is something like 32-64MB of
memory - this is barely enough memory to decode your typical 10MP
JPEG. The packing factor for SVG is typically much higher. So
I would suggest looking for ways to increase the default memory
partition of the Java Virtual Machine.