xmlgraphics-fop-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Delmelle <andreas.delme...@telenet.be>
Subject Re: Memory issue
Date Thu, 08 May 2008 10:03:53 GMT
On May 8, 2008, at 11:38, Jean-François El Fouly wrote:
> Andreas Delmelle a écrit :
>> Which Java VM are you using? Practically every time someone tells  
>> us about memory/GC issues, it appears they are using an  
>> implementation other than Sun (IBM, GNU...)
>> Up to now, we still have to find out why precisely non-Sun VMs  
>> have difficulties with FOP...
> Nope. I'll double check but I'm pretty sure it's a genuine Sun JVM  
> 1.5.0_11, or maybe the very minor build after.

OK. Just curious: Any chance you could test it on another build or  
maybe even Java 6?

>> How large would the resulting FO-files be if you dump them to the  
>> filesystem? The XML by itself says very little. From a 1.5MB XML,  
>> you could get a FO of a few KB or one of 26MB, depending on the  
>> stylesheet.
> 5.08 Mb.

That's not what I would call a large FO, so this should be no problem.

>> Does the stylesheet adhere to XSLT best practices? Does it  
>> generate a lot of redundant fo:blocks, fo:inlines?
> I hope not. It has been a complicated thing generated by  
> StyleVision in the very beginning but it has been simplified and  
> tweaked a lot.

In my personal experience, optimizing the stylesheet code usually  
does not offer much improvement in terms of global memory usage, but  
it could have a noticeable impact on the processing time. One of the  
things I've learned about generated XSL-FO stylesheets by Altova is  
that they add a lot of fo:inlines to specify, for example, font- 
properties on the lowest levels in the generated FO while, when  
comparing to the font-properties of the fo:inlines' parents nothing  
really changes, except for the size, style or weight. From FOP's  
point of view, that's somewhat of a waste. Much better to specify a  
global font-size on the page-sequence, and override on the lower  
levels only what is really necessary. After adapting the stylesheet  
manually, and removing the redundant fo:inlines, the stylesheet and  
the generated FO were reduced to not even half the original size.

Something else that bothered me, but I don't know if that was also  
generated by Altova, is that in one of the stylesheets I saw, the  
entire transformation was contained in one giant template... AFAIU,  
this gives little opportunity for the XSLT processor to clean up  
anything. Java 1.5 uses Xalan XSLTC by default, which converts  
templates into Java objects. One giant template would then mean one  
very long-living object that may reference numerous others for the  
whole duration of the processing run. If you look at the chain, when  
using XML+XSLT input, FOP is always the first one to finish, then the  
XSLT processor, then the XML parser.
If the XSLT processor cannot reclaim anything, this will give FOP  
less room to work with, so it ultimately runs slower. As the heap  
increases to reach the maximum, the points where the JVM will launch  
the GC by itself, will also increase. Since it cannot expand the heap  
anymore, it will try to clean up more frequently.


To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org

View raw message