Medhi and Glenn thanks for your quick replies and especially for immediately taking care of this. I investigated it a little further by creating a proof of concept font caching implementation so that we can measure the benefits. After this, it does not seem to me like too much work - it could be roughly a couple of days. Our primary target here was to improve FOP performance when used as a service in a multi-threaded application and not to externalize and decouple the font subsystem from FOP's layout system (although some improvements could be included).
So, here are a few numbers to share. Using a single thread, after a good warm up of about 200 FOP executions (XSL:FO to PDF with TTF embedding), the time to load arial.ttf or arialb.ttf gets about 5ms on a 2.66GHz Intel Core 2 Duo (from about 250ms the first time) on JDK_1.6.0_31 (FOP trunk). In our use cases, the frequently requested transformations are for documents having 4-10 pages and about 10 different fonts. The execution time for 4-10 pages (and the given complexity of layout) is 400-900ms. Font caching would save us about 50ms per execution, which is a 5.5%-12.5% improvement. For this use case (which I guess is not popular among FOP users) font caching is a marginally interesting improvement. If the use cases or those estimations change for some reason, I will open a new issue, work on properly implementing this and attach a patch. Alex Giotis On Apr 24, 2012, at 10:06 AM, mehdi houshmand wrote: > 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. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
