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:[EMAIL PROTECTED] Sent: Tuesday, December 11, 2007 7:17 PM To: [email protected] 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:[EMAIL PROTECTED] > Sent: Monday, December 10, 2007 10:07 PM > To: [email protected] > 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 <[EMAIL PROTECTED]> >>> To: [email protected] >>> 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. >>>> >>>> >>>> >>> >>> >>> >>> >>> >> > > >
