I ran my test cases against fop-trunk as of 08/03 and am seeing a very good boost in performance. I profiled against the same test case that produced loitering objects in fop 0.92beta, and did NOT find any loitering objects with the trunk code. The memory usage also seems to be very stable and I see more frequent garbage collections than it used to be in 0.92beta. Overall, the process seem to use less memory than before.
Below are some comparisons from my test environment :
Total pages processed : 12000 approx (split up as 1500 pages per pdf in a loop)
1. Memory usage : FOP 0.92beta started of with 500MB and went all the way upto 1.2 GB easily and JVM crashed after processing 5000 pages approx. The latest version used upto a max of 750 MB (from 500 MB initial) and never went beyond that.
2. Processing Time : 0.92 beta slowed down gradually from 4 minutes per 1500 page pdf to 15 min, when finally the JVM crashed. But the latest code took consistently 3-4 min to produce 1500 pages.
I'm not sure if the above comparison makes sense to anyone, but I just wanted to report for comparisons sake.
Overall the performance is been good so far and I'll keep profiling the process to look for any red flags.
Let me know, if you want to track any other details.
Thanks
Karthik
Andreas L Delmelle <[EMAIL PROTECTED]> wrote:
On Aug 3, 2006, at 18:59, Jeremias Maerki wrote:
> I went looking and found that the fix is actually very easy: Just make
> sure a page-sequences FO children are unreferenced when a page-
> sequence
> is done. The PageSequenceLM is properly disposed by the
> AreaTreeHandler
> so at least the LMs were already released properly. So far I haven't
> seen any negative side-effects (like NPEs) from that change. Let's
> keep
> a eye on it, though.
Cool! Should really make a difference for the situation in the OP on
fop-users. IIRC, the order of magnitude there was several thousands
of pages...
Karthik, can you try the latest SVN trunk version, and see if things
improve for you? If not, don't hesitate to report back.
Still got a few less important improvements on my list, but deferring
the marker-property resolution is still first in line ATM. Funny,
didn't seem too difficult at first, until I made the first changes,
and got a little more than I bargained for... ;)
Thanks,
Andreas
