Hi, I'll address your concerns inline:
2012/4/24 Αναστάσιος Χαρούλης <[email protected]> > 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 feat. 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. <snip/> Hope that helps, Mehdi
