Re: spending too much time in PropertyList.findProperty
Thorbjørn Ravn Andersen wrote: I have now made a comparison between 0.20.5 and the latest maintainance code in CVS, and I do not see the effects described above. I have tested with the sample AWT-previewer in FOP, and found that the memory footprint are very similar, but I will now check in the actual environment. Do I need to provide some configuration parameters which may change the behaviour of FOP? The changes to Table performance dont apply to AWT Renderer mainly because AWT Rendering uses very different code to the main part of FOP's layout/rendering engine, which is geared up for PDF, Postscript and other print formats. snip/ By accident I first checked with the code in HEAD, which did not work well, so I am convinced that 1.0 is still some time away :) Could you elaborate on what isnt working? One of my current goals is to get the development version working to a similar level as 0.20.5. Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: spending too much time in PropertyList.findProperty
Chris Bowditch wrote: The changes to Table performance dont apply to AWT Renderer mainly because AWT Rendering uses very different code to the main part of FOP's layout/rendering engine, which is geared up for PDF, Postscript and other print formats. Now I have done a quick test of this on our server with a large print. With 0.20.5 I end up with a footprint after FOP has run of 120 Mb, which falls to 20 Mb, and with the latest CVS I end up with 96 Mb which also falls to 20 Mb.I Thank you for letting me know. The saving is enough to make a difference. By accident I first checked with the code in HEAD, which did not work well, so I am convinced that 1.0 is still some time away :) Could you elaborate on what isnt working? One of my current goals is to get the development version working to a similar level as 0.20.5. I just ran the sample FO file described above through. No tables showed up, and a lot of text was put on top of each other in a single place. This was AWT only. Feel free to download and try. -- Thorbjoern Ravn Andersen ...plus...Tubular Bells! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: spending too much time in PropertyList.findProperty
Steven McNeel wrote: (2) org.apache.fop.fo.PropertyList.findProperty - 26.4% - this is the other main culprit. The time spent here is divided fairly evenly among the following three methods of PropertyListBuilder: computeProperty - 8.8% isCorrespondingForced - 5.7% getShorthand - 5.8% Similar numbers are found with OptimizeIt (6.21%, 7.9%, 7.78% respectively) with JDK 1.4.1 under Windows with FOP 0.20.5. Those three were the top 3 hotspots. It also appears that I have CPU and memory problems with FOP due to too complex tables. -- Thorbjoern Ravn Andersen ...plus...Tubular Bells! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: spending too much time in PropertyList.findProperty
Thorbjørn Ravn Andersen wrote: It also appears that I have CPU and memory problems with FOP due to too complex tables. I suspect this is be cause row and cell areas are referenced from their corresponding FOs itself and are therefore kept in memory together with all their descendants until the page sequence is completely rendered (in contrast to all other area objects which are reclaimed after a page is rendered). There is a fix for this in CVS. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: spending too much time in PropertyList.findProperty
On Thu, 2004-04-15 at 15:53, Steven McNeel wrote: Thanks for the response. The answers to your questions are: i) Yes, I'm using the HEAD. ii) I'm using JProbe on Solaris 8.5 for profiling. I had inaccurate results with JMP and got no sympathy from the author of JMP when I mentioned it. Check the archives for 'Measure accurately'. http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgId=1167985 iii) Here's the breakdown (percentages are cumulative time spent in method): (1) org.apache.batik.util.SoftReferenceCache$1.run - 49.4% - this one's interesting, and seems to explain why my app runs more slowly on UNIX than on Windows! Windows doesn't care if batik.jar is in the classpath; UNIX does. I'm not using any SVG in my stylesheet. Any ideas why it looks for it on UNIX, and how to get around it? Are you using the same version of the JVM on Windows and Solaris ? Are you using java -client or java -server on Solaris ? The default is -client and there is no -server JVM on Windows. (2) org.apache.fop.fo.PropertyList.findProperty - 26.4% That doesn't seem like that much. How much faster would Fop be if you cut that in half ? (13.2% would be nice but won't speed things up by an order of magnitude). OTOH I always get suspicous when the high-runner is in a library associated with implementation of some rare language 'feature'*. SoftReferenceCache$1 could bear investigation. * I was a PL/I programmer many years ago. - this is the other main culprit. The time spent here is divided fairly evenly among the following three methods of PropertyListBuilder: computeProperty - 8.8% isCorrespondingForced - 5.7% getShorthand - 5.8% John Austin [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: spending too much time in PropertyList.findProperty
Before we embark on another performance-of-properties thread, a couple of questions: i) Which version of Fop is involved ? I'd guess you are using HEAD, but this needs to be clear. ii) Which profiler are you using ? I ask because I got burned with measurements using a profiler that does not handle recursion properly. iii) What are the percentages ? Which methods are high-runners ? On Wed, 2004-04-14 at 17:29, Steven McNeel wrote: Hello, I'm generating a complex PDF from a big FO document, with lots of fo:block elements. It takes about 10 seconds to render a 16 page PDF. When I profiled my code, I see that most of that time is spent called Block.layout which gets called about 4,000 times. Most of its time is spent calling PropertyList.get (for a total of nearly 400,000 times!). The PropertyList.get method calls an overloaded version of itself, which in turn calls PropertyList.findProperty a whopping 1,500,000 times. My question is: as an FO stylesheet writer, is there any way I can arrange my use of fo:block elements, or the attributes therein, to decrease the number of lookups on the PropertyList object? Or, is there anything tricky I can do, perhaps in the FOP code itself, to default some integers into the different properties so that FOP doesn't even have to look them up? (If anyone is interested in seeing what is probably an overly-complex FO stylesheet, and is interested in pointing out my rookie mistakes, that would be fantastic, but otherwise, some advice on my questions above would be great.) Thanks! -Steve McNeel _ Watch LIVE baseball games on your computer with MLB.TV, included with MSN Premium! http://join.msn.com/?page=features/mlbpgmarket=en-us/go/onm00200439ave/direct/01/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- John Austin [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: spending too much time in PropertyList.findProperty
Thanks for the response. The answers to your questions are: i) Yes, I'm using the HEAD. ii) I'm using JProbe on Solaris 8.5 for profiling. iii) Here's the breakdown (percentages are cumulative time spent in method): (1) org.apache.batik.util.SoftReferenceCache$1.run - 49.4% - this one's interesting, and seems to explain why my app runs more slowly on UNIX than on Windows! Windows doesn't care if batik.jar is in the classpath; UNIX does. I'm not using any SVG in my stylesheet. Any ideas why it looks for it on UNIX, and how to get around it? (2) org.apache.fop.fo.PropertyList.findProperty - 26.4% - this is the other main culprit. The time spent here is divided fairly evenly among the following three methods of PropertyListBuilder: computeProperty - 8.8% isCorrespondingForced - 5.7% getShorthand - 5.8% -Steve _ Is your PC infected? Get a FREE online computer virus scan from McAfee® Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
