FOP Issues
Locked
 
|
I am having some trouble with FOP. It appears that performance suffers exponentially for each additional page that is written in the body (overflowing to the next page). Two pages takes about a minute to render. Five pages takes about 10 minutes. Ten pages takes about a half hour. Plenty of memory available in the JVM, plenty of CPU available as well. It completes the screen renderer quickly and gets stuck in the FOP portion. Any hints or OOTB templates that would mimic the page overflow that I can test to see if it's choking on my template or if it's just choking period? I've tried it with both .93 and .94. |
|
|
https://issues.apache.org/jira/browse/OFBIZ-1401
Chris Howe wrote: > I am having some trouble with FOP. It appears that performance suffers > exponentially for each additional page that is written in the body > (overflowing to the next page). Two pages takes about a minute to render. > Five pages takes about 10 minutes. Ten pages takes about a half > hour. Plenty of memory available in the JVM, plenty of CPU available as > well. It completes the screen renderer quickly and gets stuck in the FOP > portion. Any hints or OOTB templates that would mimic the page > overflow that I can test to see if it's choking on my template or if it's > just choking period? I've tried it with both .93 and .94. > > > |
|
|
In reply to this post by cjhowe
It helps if one (me) reads before applying a solution. I had applied Christian's patch to trunk and came up empty. I just did a c/o of 4.0 and viola...works OOTB. Adrian, I share your sentiments on the issue. That was the most draining exercise I've gone through with OFbiz in I don't know how long. Are there really that many files where the culprit could be?
----- Original Message ---- From: Adrian Crum <[hidden email]> To: [hidden email] Sent: Monday, December 10, 2007 9:44:23 AM Subject: Re: FOP Issues https://issues.apache.org/jira/browse/OFBIZ-1401 Chris Howe wrote: > I am having some trouble with FOP. It appears that performance suffers > exponentially for each additional page that is written in the body > (overflowing to the next page). Two pages takes about a minute to render. > Five pages takes about 10 minutes. Ten pages takes about a half > hour. Plenty of memory available in the JVM, plenty of CPU available as > well. It completes the screen renderer quickly and gets stuck in the FOP > portion. Any hints or OOTB templates that would mimic the page > overflow that I can test to see if it's choking on my template or if it's > just choking period? I've tried it with both .93 and .94. > > > |
|
|
So much has changed between trunk and R4 that it would be a very time consuming task to go through a
list of changed files to see which one caused the problem. That's why I suggested a profiler - it would spot the culprit right away. Chris Howe wrote: > It helps if one (me) reads before applying a solution. I had applied Christian's patch to trunk and came up empty. I just did a c/o of 4.0 and viola...works OOTB. Adrian, I share your sentiments on the issue. That was the most draining exercise I've gone through with OFbiz in I don't know how long. Are there really that many files where the culprit could be? > > ----- Original Message ---- > From: Adrian Crum <[hidden email]> > To: [hidden email] > Sent: Monday, December 10, 2007 9:44:23 AM > Subject: Re: FOP Issues > > > https://issues.apache.org/jira/browse/OFBIZ-1401 > > Chris Howe wrote: > > >>I am having some trouble with FOP. It appears that performance > > suffers > >> exponentially for each additional page that is written in the body >> (overflowing to the next page). Two pages takes about a minute to > > render. > >> Five pages takes about 10 minutes. Ten pages takes about a half >> hour. Plenty of memory available in the JVM, plenty of CPU > > available as > >> well. It completes the screen renderer quickly and gets stuck in > > the FOP > >> portion. Any hints or OOTB templates that would mimic the page >> overflow that I can test to see if it's choking on my template or if > > it's > >> just choking period? I've tried it with both .93 and .94. >> >> >> > > > > > > |
|
|
Or just hire a reverse-engineer to take this apart for you quickly. On average, 100K lines of
codes can be processed (or eliminated from "suspects list") inside of 1 hour. I still haven't found a profiler software that can do what my human engineers do well. Some things just can't be done by computers (yet). Jonathon Adrian Crum wrote: > So much has changed between trunk and R4 that it would be a very time > consuming task to go through a list of changed files to see which one > caused the problem. That's why I suggested a profiler - it would spot > the culprit right away. > > Chris Howe wrote: > >> It helps if one (me) reads before applying a solution. I had applied >> Christian's patch to trunk and came up empty. I just did a c/o of 4.0 >> and viola...works OOTB. Adrian, I share your sentiments on the >> issue. That was the most draining exercise I've gone through with >> OFbiz in I don't know how long. Are there really that many files >> where the culprit could be? >> >> ----- Original Message ---- >> From: Adrian Crum <[hidden email]> >> To: [hidden email] >> Sent: Monday, December 10, 2007 9:44:23 AM >> Subject: Re: FOP Issues >> >> >> https://issues.apache.org/jira/browse/OFBIZ-1401 >> >> Chris Howe wrote: >> >> >>> I am having some trouble with FOP. It appears that performance >> >> suffers >> >>> exponentially for each additional page that is written in the body >>> (overflowing to the next page). Two pages takes about a minute to >> >> render. >> >>> Five pages takes about 10 minutes. Ten pages takes about a half >>> hour. Plenty of memory available in the JVM, plenty of CPU >> >> available as >> >>> well. It completes the screen renderer quickly and gets stuck in >> >> the FOP >> >>> portion. Any hints or OOTB templates that would mimic the page >>> overflow that I can test to see if it's choking on my template or if >> >> it's >> >>> just choking period? I've tried it with both .93 and .94. >>> >>> >>> >> >> >> >> >> >> > > |
|
|
Jonathon
The Borland profiler is exellent (if they still even sell it) if you can afford it. You can/could also download it to use for free for a week, but it take a day to get things all set up, so you really only have 6 days. I payed licensing fees for it for a couple of years, but stopped when the need went away. Skip -----Original Message----- From: Jonathon -- Improov [mailto:[hidden email]] Sent: Monday, December 10, 2007 10:07 PM To: [hidden email] Subject: Re: FOP Issues Or just hire a reverse-engineer to take this apart for you quickly. On average, 100K lines of codes can be processed (or eliminated from "suspects list") inside of 1 hour. I still haven't found a profiler software that can do what my human engineers do well. Some things just can't be done by computers (yet). Jonathon Adrian Crum wrote: > So much has changed between trunk and R4 that it would be a very time > consuming task to go through a list of changed files to see which one > caused the problem. That's why I suggested a profiler - it would spot > the culprit right away. > > Chris Howe wrote: > >> It helps if one (me) reads before applying a solution. I had applied >> Christian's patch to trunk and came up empty. I just did a c/o of 4.0 >> and viola...works OOTB. Adrian, I share your sentiments on the >> issue. That was the most draining exercise I've gone through with >> OFbiz in I don't know how long. Are there really that many files >> where the culprit could be? >> >> ----- Original Message ---- >> From: Adrian Crum <[hidden email]> >> To: [hidden email] >> Sent: Monday, December 10, 2007 9:44:23 AM >> Subject: Re: FOP Issues >> >> >> https://issues.apache.org/jira/browse/OFBIZ-1401 >> >> Chris Howe wrote: >> >> >>> I am having some trouble with FOP. It appears that performance >> >> suffers >> >>> exponentially for each additional page that is written in the body >>> (overflowing to the next page). Two pages takes about a minute to >> >> render. >> >>> Five pages takes about 10 minutes. Ten pages takes about a half >>> hour. Plenty of memory available in the JVM, plenty of CPU >> >> available as >> >>> well. It completes the screen renderer quickly and gets stuck in >> >> the FOP >> >>> portion. Any hints or OOTB templates that would mimic the page >>> overflow that I can test to see if it's choking on my template or if >> >> it's >> >>> just choking period? I've tried it with both .93 and .94. >>> >>> >>> >> >> >> >> >> >> > > |
|
|
Eclipse TPTP has a profiler which is decent. You can even profile
applications with one click from within Eclipse. Raj Skip wrote: > Jonathon > > The Borland profiler is exellent (if they still even sell it) if you can > afford it. You can/could also download it to use for free for a week, but > it take a day to get things all set up, so you really only have 6 days. I > payed licensing fees for it for a couple of years, but stopped when the need > went away. > > Skip > > -----Original Message----- > From: Jonathon -- Improov [mailto:[hidden email]] > Sent: Monday, December 10, 2007 10:07 PM > To: [hidden email] > Subject: Re: FOP Issues > > > Or just hire a reverse-engineer to take this apart for you quickly. On > average, 100K lines of > codes can be processed (or eliminated from "suspects list") inside of 1 > hour. > > I still haven't found a profiler software that can do what my human > engineers do well. Some things > just can't be done by computers (yet). > > Jonathon > > Adrian Crum wrote: > >> So much has changed between trunk and R4 that it would be a very time >> consuming task to go through a list of changed files to see which one >> caused the problem. That's why I suggested a profiler - it would spot >> the culprit right away. >> >> Chris Howe wrote: >> >> >>> It helps if one (me) reads before applying a solution. I had applied >>> Christian's patch to trunk and came up empty. I just did a c/o of 4.0 >>> and viola...works OOTB. Adrian, I share your sentiments on the >>> issue. That was the most draining exercise I've gone through with >>> OFbiz in I don't know how long. Are there really that many files >>> where the culprit could be? >>> >>> ----- Original Message ---- >>> From: Adrian Crum <[hidden email]> >>> To: [hidden email] >>> Sent: Monday, December 10, 2007 9:44:23 AM >>> Subject: Re: FOP Issues >>> >>> >>> https://issues.apache.org/jira/browse/OFBIZ-1401 >>> >>> Chris Howe wrote: >>> >>> >>> >>>> I am having some trouble with FOP. It appears that performance >>>> >>> suffers >>> >>> >>>> exponentially for each additional page that is written in the body >>>> (overflowing to the next page). Two pages takes about a minute to >>>> >>> render. >>> >>> >>>> Five pages takes about 10 minutes. Ten pages takes about a half >>>> hour. Plenty of memory available in the JVM, plenty of CPU >>>> >>> available as >>> >>> >>>> well. It completes the screen renderer quickly and gets stuck in >>>> >>> the FOP >>> >>> >>>> portion. Any hints or OOTB templates that would mimic the page >>>> overflow that I can test to see if it's choking on my template or if >>>> >>> it's >>> >>> >>>> just choking period? I've tried it with both .93 and .94. >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>> >> > > > > |
|
|
In reply to this post by SkipDever
I think I mis-read "profiler" for "software that finds bugs". Humans find bugs faster than
software can, if software even can find bugs at all. Yeah, a profiler can quickly time an entire application, and show the bottlenecks. As for "software that finds bugs", software that finds memory leaks can be very effective. Sounds like we're all doing the same habit. :) Get application up first, quickly. Then iron out the bottlenecks. At least twice a year, I've had to tell a programmer to stop optimizing a piece of code to death and move on with completing the software. I get a vicious response almost all the time. :/ Thanks for tips. Jonathon Skip wrote: > Jonathon > > The Borland profiler is exellent (if they still even sell it) if you can > afford it. You can/could also download it to use for free for a week, but > it take a day to get things all set up, so you really only have 6 days. I > payed licensing fees for it for a couple of years, but stopped when the need > went away. > > Skip > > -----Original Message----- > From: Jonathon -- Improov [mailto:[hidden email]] > Sent: Monday, December 10, 2007 10:07 PM > To: [hidden email] > Subject: Re: FOP Issues > > > Or just hire a reverse-engineer to take this apart for you quickly. On > average, 100K lines of > codes can be processed (or eliminated from "suspects list") inside of 1 > hour. > > I still haven't found a profiler software that can do what my human > engineers do well. Some things > just can't be done by computers (yet). > > Jonathon > > Adrian Crum wrote: >> So much has changed between trunk and R4 that it would be a very time >> consuming task to go through a list of changed files to see which one >> caused the problem. That's why I suggested a profiler - it would spot >> the culprit right away. >> >> Chris Howe wrote: >> >>> It helps if one (me) reads before applying a solution. I had applied >>> Christian's patch to trunk and came up empty. I just did a c/o of 4.0 >>> and viola...works OOTB. Adrian, I share your sentiments on the >>> issue. That was the most draining exercise I've gone through with >>> OFbiz in I don't know how long. Are there really that many files >>> where the culprit could be? >>> >>> ----- Original Message ---- >>> From: Adrian Crum <[hidden email]> >>> To: [hidden email] >>> Sent: Monday, December 10, 2007 9:44:23 AM >>> Subject: Re: FOP Issues >>> >>> >>> https://issues.apache.org/jira/browse/OFBIZ-1401 >>> >>> Chris Howe wrote: >>> >>> >>>> I am having some trouble with FOP. It appears that performance >>> suffers >>> >>>> exponentially for each additional page that is written in the body >>>> (overflowing to the next page). Two pages takes about a minute to >>> render. >>> >>>> Five pages takes about 10 minutes. Ten pages takes about a half >>>> hour. Plenty of memory available in the JVM, plenty of CPU >>> available as >>> >>>> well. It completes the screen renderer quickly and gets stuck in >>> the FOP >>> >>>> portion. Any hints or OOTB templates that would mimic the page >>>> overflow that I can test to see if it's choking on my template or if >>> it's >>> >>>> just choking period? I've tried it with both .93 and .94. >>>> >>>> >>>> >>> >>> >>> >>> >>> >> > > > |
|
|
Jonathon
Tried and true: 1. Make it work 2. Make it right 3. Make it fast if required. Skip -----Original Message----- From: Jonathon -- Improov [mailto:[hidden email]] Sent: Tuesday, December 11, 2007 7:17 PM To: [hidden email] Subject: Re: FOP Issues I think I mis-read "profiler" for "software that finds bugs". Humans find bugs faster than software can, if software even can find bugs at all. Yeah, a profiler can quickly time an entire application, and show the bottlenecks. As for "software that finds bugs", software that finds memory leaks can be very effective. Sounds like we're all doing the same habit. :) Get application up first, quickly. Then iron out the bottlenecks. At least twice a year, I've had to tell a programmer to stop optimizing a piece of code to death and move on with completing the software. I get a vicious response almost all the time. :/ Thanks for tips. Jonathon Skip wrote: > Jonathon > > The Borland profiler is exellent (if they still even sell it) if you can > afford it. You can/could also download it to use for free for a week, but > it take a day to get things all set up, so you really only have 6 days. I > payed licensing fees for it for a couple of years, but stopped when the need > went away. > > Skip > > -----Original Message----- > From: Jonathon -- Improov [mailto:[hidden email]] > Sent: Monday, December 10, 2007 10:07 PM > To: [hidden email] > Subject: Re: FOP Issues > > > Or just hire a reverse-engineer to take this apart for you quickly. On > average, 100K lines of > codes can be processed (or eliminated from "suspects list") inside of 1 > hour. > > I still haven't found a profiler software that can do what my human > engineers do well. Some things > just can't be done by computers (yet). > > Jonathon > > Adrian Crum wrote: >> So much has changed between trunk and R4 that it would be a very time >> consuming task to go through a list of changed files to see which one >> caused the problem. That's why I suggested a profiler - it would spot >> the culprit right away. >> >> Chris Howe wrote: >> >>> It helps if one (me) reads before applying a solution. I had applied >>> Christian's patch to trunk and came up empty. I just did a c/o of 4.0 >>> and viola...works OOTB. Adrian, I share your sentiments on the >>> issue. That was the most draining exercise I've gone through with >>> OFbiz in I don't know how long. Are there really that many files >>> where the culprit could be? >>> >>> ----- Original Message ---- >>> From: Adrian Crum <[hidden email]> >>> To: [hidden email] >>> Sent: Monday, December 10, 2007 9:44:23 AM >>> Subject: Re: FOP Issues >>> >>> >>> https://issues.apache.org/jira/browse/OFBIZ-1401 >>> >>> Chris Howe wrote: >>> >>> >>>> I am having some trouble with FOP. It appears that performance >>> suffers >>> >>>> exponentially for each additional page that is written in the body >>>> (overflowing to the next page). Two pages takes about a minute to >>> render. >>> >>>> Five pages takes about 10 minutes. Ten pages takes about a half >>>> hour. Plenty of memory available in the JVM, plenty of CPU >>> available as >>> >>>> well. It completes the screen renderer quickly and gets stuck in >>> the FOP >>> >>>> portion. Any hints or OOTB templates that would mimic the page >>>> overflow that I can test to see if it's choking on my template or if >>> it's >>> >>>> just choking period? I've tried it with both .93 and .94. >>>> >>>> >>>> >>> >>> >>> >>> >>> >> > > > |
«
Return to OFBiz - User
|
1 view|%1 views
| Free forum by Nabble | Edit this page |