Memory usage optimisations - part 2

[Richard Huxton <de...@archonet.com>]

Been doing more testing on optimising FOP's memory usage, and I just want to
check I'm not doing anything stupid.

1. Am I right in thinking that font and border properties *cannot* change
after the FO tree has been built?

2. Is it valid to measure memory usage using
    Runtime rt = Runtime.getRuntime()
    rt.totalMemory() - rt.freeMemory()

3. Should I be forcing the garbage-collector to run before checking these
values, I assume if I get an "out of memory" error, it's already tried the
garbage collector?

Basically, for my (somewhat pathological) test case - a table with 12
columns and 176 rows, 12 different borders on the cells I get the following
(all figures are in MB):

              patched   recent CVS
Pre-parsing     1.16        1.03
Pre-layout      5.32       14.23
Pre-render     11.02       51.39
At Finish      13.15       57.63

This is a _lot_ more than I was expecting, so I figure I'm missing
something.

TIA

- Richard Huxton

Re: Memory usage optimisations - part 2

[Richard Huxton <de...@archonet.com>]

----- Original Message -----
From: "Kelly Campbell" <ca...@camk.net>
To: <fo...@xml.apache.org>

> That is pretty good. You might try both cases with HAT and dig around and
> see what the memory looks like afterwards. Is your patch cleaning up old
> references which aren't needed, or just reducing the size of certain
> objects? If it's the former, than I'm not surprised with the results. If
> it's the latter than it is a bit wild, but you can't really quantify it
> with the Runtime.freeMemory() method. It really depends on how much you
> were able to reduce the size of objects, and how big the object graph
> becomes. I would definitely suggest playing around with HAT and seeing
> what new information it can give you.

Sharing access to common sets of properties in Area (fonts, borders etc) -
so they don't get created in the first place. I downloaded HAT the other
day, so I'll start playing with it.

Thanks Kelly

- Richard

Re: Memory usage optimisations - part 2

[Kelly Campbell <ca...@camk.net>]

On Fri, Nov 10, 2000 at 01:59:11PM -0000, Richard Huxton wrote:
> 2. Is it valid to measure memory usage using
>     Runtime rt = Runtime.getRuntime()
>     rt.totalMemory() - rt.freeMemory()

While this isn't completely quantitative, it's a quick and easy way to 
watch your memory usage. Real profiling tools like OptimizeIt and the 
Heap Analysis Tool are more quantitative, and allow you to see exactly 
what classes are allocating what amount.

 
> 3. Should I be forcing the garbage-collector to run before checking these
> values, I assume if I get an "out of memory" error, it's already tried the
> garbage collector?

Can't hurt, other than maybe performance-wise. Though if you're using
HotSpot, it probably won't help that much.

> Basically, for my (somewhat pathological) test case - a table with 12
> columns and 176 rows, 12 different borders on the cells I get the following
> (all figures are in MB):
> 
>               patched   recent CVS
> Pre-parsing     1.16        1.03
> Pre-layout      5.32       14.23
> Pre-render     11.02       51.39
> At Finish      13.15       57.63

That is pretty good. You might try both cases with HAT and dig around and
see what the memory looks like afterwards. Is your patch cleaning up old
references which aren't needed, or just reducing the size of certain
objects? If it's the former, than I'm not surprised with the results. If 
it's the latter than it is a bit wild, but you can't really quantify it 
with the Runtime.freeMemory() method. It really depends on how much you 
were able to reduce the size of objects, and how big the object graph 
becomes. I would definitely suggest playing around with HAT and seeing 
what new information it can give you.

-Kelly
-- 
Kelly A. Campbell                        Software Engineer
camk@channelpoint.com                    Channelpoint, Inc.
camk@camk.net  camk@merlotxml.org        Colorado Springs, Co.