xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dario Laera <la...@cs.unibo.it>
Subject Re: Active node tree pruning in FOP trunk
Date Tue, 28 Oct 2008 17:47:38 GMT
Hi Andreas!

Il giorno 27/ott/08, alle ore 18:37, Andreas Delmelle ha scritto:

> If I'm guessing correctly, a nice demonstration to see if there are  
> additional benefits to your proposal, would be to try pasting the  
> text of a short to medium-sized book into one single monolithic  
> fo:block. Don't use linefeed preservation, and plain start- 
> alignment. The number of break-possibilities the algorithm has to  
> consider becomes so large, that you easily need +500MB of heap for  
> about 40 pages. (I did this test some time ago, and then I had to  
> give the JVM at least 720MB of heap to render a block with the  
> content of Shakespeare's Hamlet.)
> Not a real-life use case, but always a very interesting test to see  
> whether the line-breaking algorithm has scaleability issues.

I've put the "Pulp Fiction" scenario into a single block (Shakespeare,  
please, don't be offended :P), tried with both start and justify  
alignment: it always fall down in forced mode and, without pruning,  
goes out of memory with a limit of 700MB (tried with both threshold=10| 
20). With pruning enabled (configured to be activated when there are  
more than 500 active node) the maximum amount of memory is 70MB, the  
initial tree depth is 82 then reduced to 54. The resulting pdf is 69  
pages long.

I want to quote the thread regarding pruning in prototype as someone  
may have not read it: the pruning technique is a way to keep the  
active node set below a reasonable bound, but it's not the optimal  
solution. It is necessary for rendering pages asap in the prototype,  
but this is not the case in trunk. I developed it in trunk mainly to  
see whether this was working properly in the real world and to measure  
the performance gain. I think that a solution that can be enabled from  
the command line to improve performance in (not so) extreme cases  
would be a nice thing, but probably the pruning as it is now should be  
Another important reason is that it is totally unaware of fitness  
class: this is my fault, initially I didn't realized how fitness class  
was working and I ignored it. I need to study the argument to say if  
pruning can be adapted to work with fitness class.


View raw message