FO Properties and memory usage
Hi, I've been experiencing a couple of problems lately regarding speed and memory usage when generating some large fop reports (around 42MB .fo) Having run Hat on the hprof dump and taken a closer look at the code I see an awful lot of objects which don't appear to serve any useful purpose. e.g. ~38000 instances of CommonAural, CommonAccessibility, etc. which are never used. It seems like almost every class in the fo tree is storing redundant properties. Is there any reason why I shouldn't remove the worst offenders and submit the appropriate patch? Regards, Richard
DO NOT REPLY [Bug 41019] - Left-align oddness with long, unbreakable strings following
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=41019. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=41019 --- Additional Comments From [EMAIL PROTECTED] 2006-11-22 08:29 --- Created an attachment (id=19160) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=19160action=view) FO file illustrating the problem Convert this file to PDF with trunk r477112 to see the problem. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: FO Properties and memory usage
On Nov 22, 2006, at 13:30, [EMAIL PROTECTED] wrote: Hi Richard, I've been experiencing a couple of problems lately regarding speed and memory usage when generating some large fop reports (around 42MB .fo) Having run Hat on the hprof dump and taken a closer look at the code I see an awful lot of objects which don't appear to serve any useful purpose. e.g. ~38000 instances of CommonAural, CommonAccessibility, etc. which are never used. It seems like almost every class in the fo tree is storing redundant properties. Is there any reason why I shouldn't remove the worst offenders and submit the appropriate patch? Interesting info, and it somewhat confirms my suspicions... although we need to take care: just because they are currently not effectively used in the process doesn't mean that they are completely superfluous or redundant. Just because we currently don't have a renderer for which the CommonAural properties make sense, does not mean we never will incorporate such a renderer into FOP. If we ever do, those properties will have to be re-introduced anyway... OTOH, if you feel like investigating further, I personally would be very interested to see if the properties implementation cannot be optimized in other ways than simply removing them as members from the FOs. I recently mentioned the idea of flyweights. Take for example a property for 'font-size=10pt'. In the current implementation, if this property occurs on a thousand different FOs, there will be exactly as many Property instances created for it, while this could be reduced to one. All the related FOs can then share a reference to that one single instance. We would add a little overhead, since for each property we'd need to check if an instance with the exact same property value is already present in the pool... but this small overhead would drastically reduce the memory usage IIC. Cheers, Andreas
Re: DO NOT REPLY [Bug 40271] - auto table layout -- dirty draft
On Nov 22, 2006, at 15:23, [EMAIL PROTECTED] wrote: Andrejus, --- Additional Comments From [EMAIL PROTECTED] 2006-11-22 06:23 --- (In reply to comment #47) Don't think SVG is a problem... If you insist on JPEG or GIF, there's always Batik to transcode it :) I'm just trying to find kind of common denominator for that diagramming when others could also easy review/comment. So far I was not able to view generated SVG correctly inside my IE6 or Firefox 2.0. If you use any other open source/free viewer for that and could see everything correctly - please advice. Haven't tried it myself, but you could try running the SVG through Batik Squiggle. It's as free and open-source as it gets, and... it's a sibling to FOP under the XML Graphics umbrella. :) Cheers, Andreas
