xmlgraphics-fop-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Αναστάσιος Χαρούλης <tcharou...@gmail.com>
Subject Re: Fop Performance degradation after upgrading from jdk 6 u18 to u19
Date Wed, 25 Apr 2012 15:47:10 GMT
Thank you for your quick replies.

There is a filed bug :

https://issues.apache.org/bugzilla/show_bug.cgi?id=53148

The problem is resolved.

Στις 24 Απριλίου 2012 10:06 π.μ., ο χρήστης mehdi houshmand <
med1985@gmail.com> έγραψε:

> Hi,
>
> 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
> 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
>

Mime
View raw message