xmlgraphics-fop-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mehdi houshmand <med1...@gmail.com>
Subject Re: Fop Performance degradation after upgrading from jdk 6 u18 to u19
Date Tue, 24 Apr 2012 07:06:03 GMT

I'll address your concerns inline:

2012/4/24 Αναστάσιος Χαρούλης <tcharoulis@gmail.com>

> Hello,
> We are using Apache FOP 1.0 to create Postscript documents from xml files. After upgrading
the Java Virtual Machine from 1.6 update 18 to 1.6 update 19, we noticed important performance
degradation. The FOP execution time was increased about 25% - 35% (depends on the number of
executions). After investigating this, we concluded that the code that was responsible for
this delay was in the method setValue of inner class BeanSetter of class o.a.f.fonts.type1.AFPParser.
This method uses reflection to set the value of a bean and our tests showed that the time
to execute a reflection call like this was increased in jdk6 u19. We also noticed that for
each FOP execution (instantiation of a org.apache.fop.apps.Fop object) the fonts are loaded
in memory (field org.apache.fop.fonts.FontInfo in class AreaTreeHandler) .
I think you mean o.a.f.fonts.type1.AFMParser (very different to an AFP
parser) but yes, that mechanism could work just without the use of beans,
but it's a fickle mechanism and it would have to be done with care.

We are wondering if there is a plan for caching the loaded fonts in an
object that is reused between successive executions (e.g. in the
org.apache.fop.apps.FopFactory). This would mean that the extra cost
would occur only in the first execution. Do you think this is a good
idea or is there a specific reason for the fonts not to be cached ?
> No, as far as I know font caching isn't really on anyone's agenda. If
someone wanted to do this properly it would be a significant amount of
work. The fonts system would have to be externalized so that it behaved
more like a font provision service rather than the tight coupling to FOPs
layout system. This would mean a lot of code redesign and that's no small

If the fonts caching is not a good idea, do you think the use of
reflection in the BeanSetter class could be avoided?
> Font caching is a good idea, it's just a lot of work... And I do think the
BeanSetter could be avoided, but the current code is battle-hardened so
you'd just have to make sure you test it thoroughly to avoid regressions. I
wanted remove the BeanSetter system when working in that initially, but as
always more pressing concerns took over.


Hope that helps,


View raw message