please file one ore more bugs at [1], product "Fop", and please ensure the
following are attached to each bug:

   - a "maximally minimal" input FO files that demonstrates problem
   - an output file (PDF, AFP, etc.,) relevant to running your input file
   - console log output
   - version information (fop version, jdk version, etc)

also, you may wish to review the problem reported at [2] to see if it is
relevant to what you are seeing

[1] https://issues.apache.org/bugzilla/enter_bug.cgi
[2] https://issues.apache.org/bugzilla/show_bug.cgi?id=51149

regarding plans to cache loaded fonts between successive reuses of an
FopFactory instance, there aren't any as far as I'm aware; so if you wish,
you can file a bug on this with severity "enhancement"

as an fyi, one way to reduce font load time is to configure fop to only
load the fonts you need, i.e., don't use <auto-detect/> and limit the fonts
listed in the config file to those you use; this is just a possible
workaround though, to reduce the impact you are encountering

2012/4/24 Αναστάσιος Χαρούλης <tcharou...@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) .
>
>
> 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 ?
>
>
> If the fonts caching is not a good idea, do you think the use of reflection 
> in the BeanSetter class could be avoided?
>
>
> Attached you may find a sample application that demonstrates the issue. This 
> application instantiates Fop and executes a conversion 200 times. The class 
> file is foptest.FopTest. Libraries of FOP should exist in the classpath.
>
>
> (Execute java -cp ... foptest.FopTest in  the extracted folder)
>
> Also in the class foptest.ReflectionTest it is demonstrated the mentioned 
> problem with the reflection call.
>
> Note: There is no (noticed) performance degradation if only one conversion 
> runs.
>
> Thanks in advance,
>
> Tassos
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
>

Reply via email to