Hi, Manuel Mall a écrit : <snip/> > I have been following this discussion with very little attempt to > understand the intricate technical details of concurrent maps etc, but > I am wondering why we don't apply the KISS principle here? > > IIRC the original problem was that the FOP memory footprint for > rendering large documents was causing issues. One set of culprits that > were identified were the properties. Given that a FOP rendering run is > single threaded, i.e. there are no threads created within FOP, why > don't we start with a property cache per run? No threading issues, no > performance issues, and large gains in memory footprint reduction. > > That will even benefit the memory footprint of concurrent FOP runs. > Admittedly not to the extend as globally shared cache would do, but it > would be much simpler and we can use the standard Java collection > classes to implement it.
I’m afraid I must agree with Manuel here; although I’m not very familiar with that whole area and I may well be also missing something. It seems to me that the main problem of FOP is that it isn’t able to render big documents, and that properties only play a part in that problem. It might be more useful to try and optimize the whole rendering process, from which everyone will benefit, those running FOP on a server as well as all others. That’s not the same kind of effort but it’s as much important IMHO. A cache per rendering run would do the thing, wouldn’t it? Coupled with a flyweight factory for those properties with a small number of possible values, which themselves could be shared among the different threads. Also, maybe it’s worth keeping in mind that while that’s not currently the case, we want to eventually make the rendering process multi-threaded. Although the two issues might actually not interfere. WDYT? Vincent
