Two pieces of general advice:

• Always use wall clock time, not CPU time, when profiling a database application. It could be spending the majority of time waiting for responses to queries, which won't show up at all with the default of measuring CPU time.
• When you find the problem, fixing Class::DBI performance problems often involves replacing Class::DBI calls with straight DBI calls inside a small performance-sensitive section of code.

Thanks I will try that.

Feedback when DProf cease to crash ... or never if I do before.

;-)

Hmmm ... I would start with logging and timing before I jumped into any of the profile modules. That way I could narrow down the chunk(s) of code that are problematic. BTW ... I would use Benchmark's timediff method:

my $t1 = Benchmark->new()
#
# chunk of code
#
my $t2 = Benchmark->new();
my $td = timediff( $t2, $t1 );
$log->debug( "Chunk x took " . timestr( $td ) );
[download]

Theoretically, Devel::DProf should be a good way to find the parts of the program that need attention. It can tell which subs are taking up the time.

That's my "plan B" if I can't make the profiler work.

But I'd rather not touch too much code.

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!

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...

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).

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.

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

Oh, and I can feel your pain regarding non-working profilers.

/J

Thanks for the pointers.

I indeed find surprising that those modules would break so easily.

Maybe some of the modules module you are using, uses (or abuses) the debugging API, which may conflict with the profilers.

Are you able to run the same script under the debugger successfully?

The modules used should not mess with the debugger, but who knows indeed.

I did not try the debugger, but I will.

Thanks for the answer.

BTW, I am the author of Devel::FastProf and the maintainer of Devel::SmallProf and would really appreciate having bug reports for those modules describing your problems in detail!