Re: Memory measurement -- importance of Driver.reset() in Cocoon - NOT!

2003-11-24 Thread John Austin
I took a further look at some of the JVM options and ran a few 
more tests. I found  a couple of things that may be useful.

1) I have to use -Xmx400m to produce the 2000 page PDF in a 
large PDF test, 'time' reported: real ~5m user 2m57.880 ...

2) When I added -Xms400m to the same work 'time' reported: real
4m35.968s user 2m35.190s ...

This is drop in user time of 22 seconds, about 12 percent

The Cocoon Performance Tips page says we should not use -Xms.
One problem with statements of performance is they don't always 
discuss the rationale. My own feeling is that FOP will remain
problematic for large documents and this will be especially so in
server environments such as Cocoon.

3) When I add the JVM 1.4 option: '-server', executiuon gets faster.
Time reports: real 2m52.100s user 2m1.520s as improvement of
about 20 percent.

Note that 'cocoon.sh'  in the top-level directory for cocoon-2.1.3
supplies the defaults: JAVA_OPTIONS=-Xms32m -Xmx512m but does not
specify '-server'.
 


-- 
John Austin [EMAIL PROTECTED]


Re: Memory measurement -- importance of Driver.reset() in Cocoon - NOT!

2003-11-24 Thread Glen Mazza
--- John Austin [EMAIL PROTECTED] wrote:

 My own feeling is that FOP
 will remain
 problematic for large documents and this will be
 especially so in
 server environments such as Cocoon.
 

We hear you, and we do emphasize performance as one of
our main goals [1].  As always, you may wish to add a
Wiki page on things we're not doing that we should be
doing in order to speed things up.  Bugzilla may also
be a good place.  Others can comment on them that way,
and we can refine what needs to be done.

For me though, depending on the problem, there can be
a grokking delay--I tend not to act until I fully
understand the issues involved.  Also, I am currently
tied up with layout issues which preclude me from
getting too much into properties code at this time. 

But many of the other committers/contributors have
more thought-out opinions on how properties should be
handled and should be able to contribute more quickly
to your ideas.

Glen

[1]
http://marc.theaimsgroup.com/?l=fop-devm=106735192618324w=2


__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/


Re: Memory measurement -- importance of Driver.reset() in Cocoon - NOT!

2003-11-24 Thread John Austin
On Mon, 2003-11-24 at 16:23, Glen Mazza wrote:
 --- John Austin [EMAIL PROTECTED] wrote:
 
  My own feeling is that FOP
  will remain
  problematic for large documents and this will be
  especially so in
  server environments such as Cocoon.
  
 
 We hear you, and we do emphasize performance as one of
 our main goals [1].  As always, you may wish to add a
 Wiki page on things we're not doing that we should be
 doing in order to speed things up.  Bugzilla may also
 be a good place.  Others can comment on them that way,
 and we can refine what needs to be done.
 
 For me though, depending on the problem, there can be
 a grokking delay--I tend not to act until I fully
 understand the issues involved.  Also, I am currently
 tied up with layout issues which preclude me from
 getting too much into properties code at this time. 
 
 But many of the other committers/contributors have
 more thought-out opinions on how properties should be
 handled and should be able to contribute more quickly
 to your ideas.

Thanks. Sometimes Ijump on things (like a cop on a donut). 
Part of the ENTJ personality type (most engineers are ENTP
 - Perceiving vs Judgemental).

I want my focus to be on the PropertyList issue, as I feel
there are significant benefits there. I have a few miles to
go to understand the issues in PropertyList and 
PropertyListBuilder. 

I intentionally have not brought up my new observation:

obs
When I run the same test twice with a Driver.reset(), GC and
a wait in between, heap usage the first time is TWICE
the usage of the second run.  Time taken is the same.
Just somethng to wonder about, in case we stumble on a
reason.

JMP graphic available on request.

I have learned quite a bit about running FOP (and Java) for
larger files. A year ago, I had terrible trouble running FOP
in Cocoon becasue I had only 256Mb. The same task is a breeze
in the current release.

1) Large (equal) values of -Xms and -Xmx can reduce GC and
speed execution of a task. There is documented support
for this on the Sun site.

2) Use of the Server HotSpot VM makes a bigger difference
than point (1). I have submitted a fix for 'cocoon.sh' to
select this JVM. I am sure this was an oversight at Cocoon.

3) FOP and related libraries compiled with Sun's SDK can all 
be run with the current (1.4.1) IBM SDK. The GC performance
of this IBM SDK is too ugly for words. More to thnk about.

4) You can observe Garbage Collection events with the Java option:
-verbose:gc and this works similarly on both IBM and Sun run-times.
Trace syntax is quite different but you can see times and sizes.
/obs

Given that I may have p*ss*d off some Germans (my Neandertal*
comment ;-), I shall refrain from stating that there may be
something rotten in Denmark - that might annoy Shakespeare-averse
Danes ...

* I lived on Ramstein Air Force Base for 4 years. 
Many Neandertals in my high-school at Kaiserslautern!

 Glen
 
 [1]
 http://marc.theaimsgroup.com/?l=fop-devm=106735192618324w=2
 
 
 __
 Do you Yahoo!?
 Free Pop-Up Blocker - Get it now
 http://companion.yahoo.com/
-- 
John Austin [EMAIL PROTECTED]


Re: Memory measurement -- importance of Driver.reset() in Cocoon - NOT!

2003-11-20 Thread John Austin
On Fri, 2003-11-21 at 00:43, John Austin wrote:

 I mean, I wonder what Cocoon does ?

In FOPSerializer:

/**
 * Recycle serializer by removing references
 */
public void recycle() {
super.recycle();
this.driver = null;
this.renderer = null;
}

Apparently, we don't need no stinkin reset();
 
-- 
John Austin [EMAIL PROTECTED]