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

--- Comment #5 from Andreas L. Delmelle <[email protected]> 2011-05-19 
18:07:16 UTC ---
(In reply to comment #4)
> 
> 1. Your suggestion of adding (linefeed-treatment="preserve") somehow didn't
> have any visible affect. I am putting the XSL below. However, I did see that
> this reduced the memory usage which doesn't grow exponentially anymore. I 
> added
> tag to the block and other places too :-(

By 'no visible effect', do you mean in the output?

> 2. Interestingly it looks that a default line break is coming in all the feeds
> that have large content. eg. 
> 
> Interactive&lt;br&gt;Group connections222 :&lt;br&gt;
> 
> Can I use the custom BR tag to improve performance and reduce memory foot 
> print
> ?

Definitely. That gives the line-layout algorithm hints about where a break MUST
occur, and that allows at least some optimization, however... (see below)

> A writeup is mentioned at
> http://www.stylusstudio.com/xsllist/200312/post00590.html

... In cases where you are sure that the <br/> just appears in between plain
text, it is more optimal to transform it into a literal linefeed character
(U+000A), and set linefeed-treatment on the parent block.
That will reduce memory usage even further. Empty blocks generate enough
overhead to justify avoiding too many of those.

> > 3. Is there any other way to optimize performance findBreakingPoints by
> compromising formatting ? Like you mentioned a paragraph of larger than 50
> thousand characters in difficult to read anyways. All I want is that the
> paragraph gets printed even if ill formatted.

See above: I think that, apart from injecting forced breaks in the input, I do
not immediately see a way to optimize further.

-- 
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