Re: awt performance 0.93 vs 0.92beta
Andreas L Delmelle wrote: On Jan 25, 2007, at 05:28, Daniel Noll wrote: However, it seems like almost the whole stack trace could be avoided if this call cached its results somehow: org.apache.fop.fonts.Font.getCharWidth(Font.java:231) (an array of 65536 elements would be enough, but wouldn't be terribly efficient in terms of memory.) So the solution may lie in between: make the call once per *used* character. It's highly unlikely that a document will contain all 64K characters anyway... Whereas that's true (I wasn't planning to call it for all 64k characters anyway, just as necessary) I was thinking of minimising the lookup time by looking the character up in an array vs. using a HashMap. But I guess the initial version can use a HashMap and I'll see what happens from there. I guess calculating the hash will be trivial at least. :-) Daniel -- Daniel Noll Nuix Pty Ltd Suite 79, 89 Jones St, Ultimo NSW 2007, AustraliaPh: +61 2 9280 0699 Web: http://nuix.com/ Fax: +61 2 9212 6902 This message is intended only for the named recipient. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this message or attachment is strictly prohibited. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: awt performance 0.93 vs 0.92beta
On Jan 25, 2007, at 05:28, Daniel Noll wrote: However, it seems like almost the whole stack trace could be avoided if this call cached its results somehow: org.apache.fop.fonts.Font.getCharWidth(Font.java:231) (an array of 65536 elements would be enough, but wouldn't be terribly efficient in terms of memory.) So the solution may lie in between: make the call once per *used* character. It's highly unlikely that a document will contain all 64K characters anyway... Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: awt performance 0.93 vs 0.92beta
Jeremias Maerki wrote: Seeing your stacktrace and your explanations I can't help but suspect that maybe the whole AWT font handling could have a strong influence on performance. If I had free time, I think I'd profile the number of calls and run time of the Java2DFontMetrics.setFont() method. It could be that we're changing the font too often while also not reusing font instances created earlier. I think the logic there is pretty dumb (only one font is active at one point). I know from my Win32 days that allocating resources in Windows is not really a cheap operation. Maybe that gets you some more ideas in which direction to look. Well, it does look like it's using the same font file since there are no font constructors or other obviously inefficient things in that stack trace. However, it seems like almost the whole stack trace could be avoided if this call cached its results somehow: org.apache.fop.fonts.Font.getCharWidth(Font.java:231) (an array of 65536 elements would be enough, but wouldn't be terribly efficient in terms of memory.) Daniel -- Daniel Noll Nuix Pty Ltd Suite 79, 89 Jones St, Ultimo NSW 2007, AustraliaPh: +61 2 9280 0699 Web: http://nuix.com/ Fax: +61 2 9212 6902 This message is intended only for the named recipient. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this message or attachment is strictly prohibited. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: awt performance 0.93 vs 0.92beta
Seeing your stacktrace and your explanations I can't help but suspect that maybe the whole AWT font handling could have a strong influence on performance. If I had free time, I think I'd profile the number of calls and run time of the Java2DFontMetrics.setFont() method. It could be that we're changing the font too often while also not reusing font instances created earlier. I think the logic there is pretty dumb (only one font is active at one point). I know from my Win32 days that allocating resources in Windows is not really a cheap operation. Maybe that gets you some more ideas in which direction to look. Good luck! On 24.01.2007 23:22:00 Daniel Noll wrote: > Andreas L Delmelle wrote: > > On Jan 24, 2007, at 04:30, Daniel Noll wrote: > > > >> Andreas L Delmelle wrote: > >>> If it turns out that 0.93 is slower on any JVM, then if you can, > >>> please send us the FO, so we can investigate what might be causing > >>> this. Is there anything special about the FO-file? (i.e. lots of > >>> markers, images, tables, particular FO-constructs...) > >> > >> FWIW we've noticed a similar issue with speed here, although in our > >> case we were comparing the speed of 0.20.5 to 0.93 so we hadn't > >> narrowed it down to being the very latest version. The only thing > >> peculiar about our own FO files is that they are relatively heavy on > >> table usage. and often have large images (>1024px) which are scaled > >> down to a small size (~120px) for thumbnails. > > > > Important question that hasn't been asked in this particular thread: > > Does this occur only when using the AWT renderer, or is there a similar > > drop in processing speed when rendering to PDF or PS? > > > > If it happens only with AWT, then the used JVM (AWT implementation) > > could be a key factor... > > PDF is unchanged so yeah, it's probably something to do with the way AWT > is being called. > > Also, the slowdown is much more noticeable on Windows 2000. On Windows > XP it seems to be something like 1-2 times slower, on Windows 2000 we > measure it being more like 2-3 times slower. > > On Windows 2000, pausing the application randomly during the conversion, > it almost always pauses at the following point: > > > at sun.font.SunLayoutEngine.nativeLayout(Native Method) > > at sun.font.SunLayoutEngine.layout(SunLayoutEngine.java:133) > > at sun.font.GlyphLayout$EngineRecord.layout(GlyphLayout.java:611) > > at sun.font.GlyphLayout.layout(GlyphLayout.java:410) > > at > > sun.font.ExtendedTextSourceLabel.createGV(ExtendedTextSourceLabel.java:308) > > at sun.font.ExtendedTextSourceLabel.getGV(ExtendedTextSourceLabel.java:294) > > at > > sun.font.ExtendedTextSourceLabel.createLogicalBounds(ExtendedTextSourceLabel.java:208) > > at > > sun.font.ExtendedTextSourceLabel.getAdvance(ExtendedTextSourceLabel.java:117) > > at java.awt.font.TextLine.init(TextLine.java:264) > > at java.awt.font.TextLine.(TextLine.java:110) > > at java.awt.font.TextLine.fastCreateTextLine(TextLine.java:952) > > at java.awt.font.TextLayout.fastInit(TextLayout.java:585) > > at java.awt.font.TextLayout.(TextLayout.java:374) > > at > > org.apache.fop.render.java2d.Java2DFontMetrics.setFont(Java2DFontMetrics.java:306) > > at > > org.apache.fop.render.java2d.Java2DFontMetrics.hasChar(Java2DFontMetrics.java:360) > > at > > org.apache.fop.render.java2d.FontMetricsMapper.hasChar(FontMetricsMapper.java:175) > > at org.apache.fop.fonts.Font.hasChar(Font.java:189) > > at org.apache.fop.fonts.Font.getCharWidth(Font.java:231) > > at > > org.apache.fop.layoutmgr.inline.TextLayoutManager.getNextKnuthElements(TextLayoutManager.java:632) > > at > > org.apache.fop.layoutmgr.inline.LineLayoutManager.collectInlineKnuthElements(LineLayoutManager.java:658) > > at > > org.apache.fop.layoutmgr.inline.LineLayoutManager.getNextKnuthElements(LineLayoutManager.java:593) > > at > > org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:284) > > at > > org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:113) > > at > > org.apache.fop.layoutmgr.FlowLayoutManager.getNextKnuthElements(FlowLayoutManager.java:106) > > at > > org.apache.fop.layoutmgr.PageSequenceLayoutManager$PageBreaker.getNextKnuthElements(PageSequenceLayoutManager.java:272) > > at > > org.apache.fop.layoutmgr.AbstractBreaker.getNextBlockList(AbstractBreaker.java:554) > > at > > org.apache.fop.layoutmgr.PageSequenceLayoutManager$PageBreaker.getNextBlockList(PageSequenceLayoutManager.java:264) > > at > > org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:301) > > at > > org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:263) > > at > > org.apache.fop.layoutmgr.PageSequenceLayoutManager.activateLayout(PageSequenceLayoutManager.java:157) > > at > > org.apache.fop.area.AreaTreeHandler.endPageSequence(AreaTreeHandler.java:385) > > at > > org.apache.fop.fo.pagination.PageSequence.endOfN
Re: awt performance 0.93 vs 0.92beta
Andreas L Delmelle wrote: On Jan 24, 2007, at 04:30, Daniel Noll wrote: Andreas L Delmelle wrote: If it turns out that 0.93 is slower on any JVM, then if you can, please send us the FO, so we can investigate what might be causing this. Is there anything special about the FO-file? (i.e. lots of markers, images, tables, particular FO-constructs...) FWIW we've noticed a similar issue with speed here, although in our case we were comparing the speed of 0.20.5 to 0.93 so we hadn't narrowed it down to being the very latest version. The only thing peculiar about our own FO files is that they are relatively heavy on table usage. and often have large images (>1024px) which are scaled down to a small size (~120px) for thumbnails. Important question that hasn't been asked in this particular thread: Does this occur only when using the AWT renderer, or is there a similar drop in processing speed when rendering to PDF or PS? If it happens only with AWT, then the used JVM (AWT implementation) could be a key factor... PDF is unchanged so yeah, it's probably something to do with the way AWT is being called. Also, the slowdown is much more noticeable on Windows 2000. On Windows XP it seems to be something like 1-2 times slower, on Windows 2000 we measure it being more like 2-3 times slower. On Windows 2000, pausing the application randomly during the conversion, it almost always pauses at the following point: at sun.font.SunLayoutEngine.nativeLayout(Native Method) at sun.font.SunLayoutEngine.layout(SunLayoutEngine.java:133) at sun.font.GlyphLayout$EngineRecord.layout(GlyphLayout.java:611) at sun.font.GlyphLayout.layout(GlyphLayout.java:410) at sun.font.ExtendedTextSourceLabel.createGV(ExtendedTextSourceLabel.java:308) at sun.font.ExtendedTextSourceLabel.getGV(ExtendedTextSourceLabel.java:294) at sun.font.ExtendedTextSourceLabel.createLogicalBounds(ExtendedTextSourceLabel.java:208) at sun.font.ExtendedTextSourceLabel.getAdvance(ExtendedTextSourceLabel.java:117) at java.awt.font.TextLine.init(TextLine.java:264) at java.awt.font.TextLine.(TextLine.java:110) at java.awt.font.TextLine.fastCreateTextLine(TextLine.java:952) at java.awt.font.TextLayout.fastInit(TextLayout.java:585) at java.awt.font.TextLayout.(TextLayout.java:374) at org.apache.fop.render.java2d.Java2DFontMetrics.setFont(Java2DFontMetrics.java:306) at org.apache.fop.render.java2d.Java2DFontMetrics.hasChar(Java2DFontMetrics.java:360) at org.apache.fop.render.java2d.FontMetricsMapper.hasChar(FontMetricsMapper.java:175) at org.apache.fop.fonts.Font.hasChar(Font.java:189) at org.apache.fop.fonts.Font.getCharWidth(Font.java:231) at org.apache.fop.layoutmgr.inline.TextLayoutManager.getNextKnuthElements(TextLayoutManager.java:632) at org.apache.fop.layoutmgr.inline.LineLayoutManager.collectInlineKnuthElements(LineLayoutManager.java:658) at org.apache.fop.layoutmgr.inline.LineLayoutManager.getNextKnuthElements(LineLayoutManager.java:593) at org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:284) at org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:113) at org.apache.fop.layoutmgr.FlowLayoutManager.getNextKnuthElements(FlowLayoutManager.java:106) at org.apache.fop.layoutmgr.PageSequenceLayoutManager$PageBreaker.getNextKnuthElements(PageSequenceLayoutManager.java:272) at org.apache.fop.layoutmgr.AbstractBreaker.getNextBlockList(AbstractBreaker.java:554) at org.apache.fop.layoutmgr.PageSequenceLayoutManager$PageBreaker.getNextBlockList(PageSequenceLayoutManager.java:264) at org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:301) at org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:263) at org.apache.fop.layoutmgr.PageSequenceLayoutManager.activateLayout(PageSequenceLayoutManager.java:157) at org.apache.fop.area.AreaTreeHandler.endPageSequence(AreaTreeHandler.java:385) at org.apache.fop.fo.pagination.PageSequence.endOfNode(PageSequence.java:148) at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.endElement(FOTreeBuilder.java:378) at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:194) Interestingly when I try this random pausing experiment on Windows XP, it never stops there. I can't explain that... Daniel -- Daniel Noll Nuix Pty Ltd Suite 79, 89 Jones St, Ultimo NSW 2007, AustraliaPh: +61 2 9280 0699 Web: http://nuix.com/ Fax: +61 2 9212 6902 This message is intended only for the named recipient. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this message or attachment is strictly prohibited. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: awt performance 0.93 vs 0.92beta
On Jan 24, 2007, at 04:30, Daniel Noll wrote: Andreas L Delmelle wrote: If it turns out that 0.93 is slower on any JVM, then if you can, please send us the FO, so we can investigate what might be causing this. Is there anything special about the FO-file? (i.e. lots of markers, images, tables, particular FO-constructs...) FWIW we've noticed a similar issue with speed here, although in our case we were comparing the speed of 0.20.5 to 0.93 so we hadn't narrowed it down to being the very latest version. The only thing peculiar about our own FO files is that they are relatively heavy on table usage. and often have large images (>1024px) which are scaled down to a small size (~120px) for thumbnails. Important question that hasn't been asked in this particular thread: Does this occur only when using the AWT renderer, or is there a similar drop in processing speed when rendering to PDF or PS? If it happens only with AWT, then the used JVM (AWT implementation) could be a key factor... Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: awt performance 0.93 vs 0.92beta
Andreas L Delmelle wrote: If it turns out that 0.93 is slower on any JVM, then if you can, please send us the FO, so we can investigate what might be causing this. Is there anything special about the FO-file? (i.e. lots of markers, images, tables, particular FO-constructs...) FWIW we've noticed a similar issue with speed here, although in our case we were comparing the speed of 0.20.5 to 0.93 so we hadn't narrowed it down to being the very latest version. The only thing peculiar about our own FO files is that they are relatively heavy on table usage. and often have large images (>1024px) which are scaled down to a small size (~120px) for thumbnails. Daniel -- Daniel Noll Nuix Pty Ltd Suite 79, 89 Jones St, Ultimo NSW 2007, AustraliaPh: +61 2 9280 0699 Web: http://nuix.com/ Fax: +61 2 9212 6902 This message is intended only for the named recipient. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this message or attachment is strictly prohibited. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: awt performance 0.93 vs 0.92beta
On Jan 23, 2007, at 10:34, paul wrote: I'll be happy to do some investigating, but I'm also a bit pressed for time at the moment(should be doing work :). It seems to me 1.5 is still installed on the system. does someone happen to know a quick way to change between different jre's, for example with path-variables (win xp)? I don't have time for lenghty download & de-/reinstallation procedures. IIC, all that needs to be done is: a) make sure that the path to the 1.5 binary appears before that to 1.6. When you subsequently execute 'java', the 1.5 executable will be used... b) the environment variable JAVA_HOME should point to the 1.5 folder instead of 1.6 If it turns out that 0.93 is slower on any JVM, then if you can, please send us the FO, so we can investigate what might be causing this. Is there anything special about the FO-file? (i.e. lots of markers, images, tables, particular FO-constructs...) Thanks, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: awt performance 0.93 vs 0.92beta
I'll be happy to do some investigating, but I'm also a bit pressed for time at the moment(should be doing work :). It seems to me 1.5 is still installed on the system. does someone happen to know a quick way to change between different jre's, for example with path-variables (win xp)? I don't have time for lenghty download & de-/reinstallation procedures. cheers pl - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: awt performance 0.93 vs 0.92beta
paul wrote: Hello I'm running fop on my pc (windows xp, jre 1.6) locally, and just updated from fop 0.92beta to 0.93. Using AWT-mode, I find that 0.93 processes my xml and xsl much slower than 0.92beta, and less reliable. At the first try, the pdf-preview in awt usually looks mangled, only when I run it a second time with thedebug-button in the awt window, the preview looks as expected. But rendering takes so much time that I went back to using 0.92beta, which runs quick and smooth. Is this a problem documented elsewhere already? I think you are the first person to try AWT renderer on jdk 1.6. AWT Renderer is heavily dependent on JDK version. Have you tried running 1.5? Do you still observe a massive performance slowdown between 0.92 and 0.93 using 1.5? Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
awt performance 0.93 vs 0.92beta
Hello I'm running fop on my pc (windows xp, jre 1.6) locally, and just updated from fop 0.92beta to 0.93. Using AWT-mode, I find that 0.93 processes my xml and xsl much slower than 0.92beta, and less reliable. At the first try, the pdf-preview in awt usually looks mangled, only when I run it a second time with thedebug-button in the awt window, the preview looks as expected. But rendering takes so much time that I went back to using 0.92beta, which runs quick and smooth. Is this a problem documented elsewhere already? cheers paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
