Thank you, Karthik! That's very helpful information. Looks like another
little change making a huge difference. Cool!
Now, if we can free some objects even sooner FOP might even handle files
like the one from Luis Ferro with under 256MB one day. For that we'll
need to know reliably when an FO is completely processed (including area
generation). That's something that we'll also need for
page-number-citation-last, too, BTW.
On 09.08.2006 22:21:56 kar thik wrote:
> 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
> Below are some comparisons from my test environment :
> Total pages processed : 12000 approx (split up as 1500 pages per pdf in a
> 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.
> 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... ;)