Re: Profiling woes

[stiller]

in reply to Profiling woes

I'm not exactly wise, but anyway: what makes your application slow is probably tightly related to the cause of profilers deaths. I'd try to narrow the problem down as much as possible, to isolate the module / set of modules that cause trouble. Try commenting out, e.g. with POD. Is there some heavy lifting in an inner loop somewhere?

Do you have tests for the project spesific modules? They should probably be prime suspects... If you make simple tests to check their sanity, you can also to profile these tests in isolation.

Good luck!

[apl]

try to narrow the problem down as much as possible

Exactly. If it's a CGI that uses DBI, create two test programs, one that only uses the CGI functionality, the other that only performs the DBI functionality. Find which one runs slow. Break that test program down...

[goupilInside]

I actually only mentioned CGI because of eventual interaction with the profiling environment.
But the script is really dependant of getting its data from the database, hard to do without (ok I could do without if I had some stub objects and data, but I don't for now).
That's why I really thought I had a good approach with the profiling (for once).

[perrin]

what makes your application slow is probably tightly related to the cause of profilers deaths

Probably not, actually. The deaths are most likely caused by a bug in perl's debugging hooks. There's no reason to think that the part causing the crash is slow.

[goupilInside]

Well that's what I was trying to avoid thinking that profiling would give me a more elegant approach.

What makes it more tedious is that some of the modules do have documentation and tests, and tend to have been used in various other programs. Some are more in the philosophy "write once", read never ....

Thanks anyway