Andreas Delmelle a écrit :
OK. Just curious: Any chance you could test it on another build or
maybe even Java 6?
Probably, if required or useful. Our sys admins are very cooperative ;-)
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.
Yes. That is exactly what happened to the stylesheet we use. I've
reduced it drastically.
One issue with stylesheets generated by StyleVision is that you must be
careful when you tweak them to avoid certain [fo-block inside fo:inline]
combinations that make FOP crash with a stack trace and no really useful
information about what's happening or where. This bug is mentioned in
the FOP bug tracker, though in a rather raw, loose manner. I removed all
such constructs and that made the XSLT much simpler and cleaner.
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...
With the last version, or our XSLT ? this was no longer the case.
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.
Yep, that is why I've tried to be cautious not to accuse FOP publicly ;-)
The problem is in the (Xalan + FOP) subsystem and the profiling could
well show that the issue is Xalan-related.
BTW, we've made the Xalan-FOP coupling a parameter so that we can use
tight coupling (with Sax events) or loose coupling (writing the
intermediate FO files on disk). We usually use the second option, since
the possibility to read the FO intermediate code is helpful when you
debug. And I guess without being really sure that not to have Xalan and
FOP working at the same time should use less memory. This separation
probably accounts for the long execution time, but that is not an issue
since document generation does not occur often in the target system (you
can generate chapters for proofreading but you generate the whole
document once-twice a day).
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
