https://issues.apache.org/bugzilla/show_bug.cgi?id=51218

--- Comment #3 from Andreas L. Delmelle <adelme...@apache.org> 2011-05-18 
18:45:18 UTC ---
(In reply to comment #0)
> 
> 1. FOP Performs unusually SLOW if there is a large paragraph
> We have noticed that when there is an unusually large paragraph than FOP
> performance is incredibly slow. FOP takes more than 15 minutes in the method
> findBreakingPoints which is defined in BreakingAlgorithm.java. The paragraph
> size is of around 50 thousand characters. This method seems to find the best
> possible Break point. Can we not make this method return a default break point
> that works for the English language ?

Sorry, I do not understand the point you are trying to make here. 
What is 'unusual' is having a paragraph with 50K chars in the first place, and
then expecting an advanced layout algorithm to just process this as fast as one
with only 500 chars.

Admittedly, FOP has a scalability problem here, but 50K chars? Really? Who is
supposed to read that?

Could it be that the paragraph is pre-formatted, perhaps? That is: Does it
contain linefeeds that may be preserved? In that case, specify
linefeed-treatment="preserve" on the surrounding block and it will go
significantly faster.

> 
> 2. FOP uses unusually large memory when running in findBreakingPoints method
> defined in BreakingAlgorithm.java. This method starts to consume around 500 MB
> memory creating thousands of Objects of KnuthNode type. Such memory 
> consumption
> is unacceptable just for finding a line break :-(.

It is not 'finding a line-break'. It determines the most optimal line-breakS
(plural).

And again: we know of this issue, but fixing it is non-trivial, unfortunately.

> Is there a way, I can prevent this extensive memory usage and slow performance
> by using a default break ?

You can, as suggested above, make sure the linefeeds are preserved, if that is
what you mean by 'default break'. Each line will then become a sub-paragraph,
and the complete paragraph will take only a fraction of the time and memory to
process.

The only other option is to split that monster-paragraph into smaller ones.
Divide and conquer.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Reply via email to