On Aug 4, 2007, at 13:22, Vincent Hennebert wrote:

Manuel Mall a écrit :
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?

Oh, but it is Simple and Stupid. :-)
Much simpler and much more stupid than our layoutengine or hyphenator or property resolution code or...

The initial version I posted earlier was in fact so stupid it still contained a huge design flaw. Lucky for me, nobody actually took a look at the code... Either that, or I should assume that a whole lot of people looked at it, but no one understood it. But that doesn't make it 'not simple'!

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?

We have already started (a couple of months ago)... with static final caches. An idea that seems to do the job nicely, although there are some reservations on the performance penalty because the cache needs to be synchronized in that case.

OTOH, Richard also raised the question, and to be honest, I don't have a clue for the moment:
What are realistic numbers to measure that penalty with?

I tried spawning 10 threads, and the penalty was already significant, but... This is supposing that all those 10 threads would need to access the /same/ cache at the exact /same/ instant.

If each thread spends less than 10% of the time parsing properties, the chances of that happening become very little.

No threading issues, no performance issues, and large gains in memory footprint reduction.

Indeed, but I think that implementing that would be much more difficult than the current solution. Much less adhering to the beloved KISS-principle than a Simple and Stupid home-made Hashtable... :-)

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.

Yes, but see my comments above: to implement this, we would be introducing yet another set of classes, making the property resolution code even more complicated than it already is. It only / seems/ simpler...

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.

Well, if anything, the big PRO for a concurrent, thread-safe cache should precisely be the prospect of FOP multithreading *internally*. In that case, the current solution --possibly over time again backed by a standard 1.5 ConcurrentHashMap-- at least offers something which a rendering-run-local cache would lack.



Reply via email to