Re^9: System call doesn't work when there is a large amount of data in a hash

[hippo]

The problem here is that you are casting aspersions against a very widely deployed and highly respected module. I've just checked and as of right now it has 164 ++ on MetaCPAN (which is huge) and an absolute swathe of 5-star reviews on CpanRatings. So when you say something like

that devel tool couldn't estimate the correct time when there is a loop

when almost all the code it will ever be used to profile will feature loops, it seems suspicious. And when you don't then provide any code to demonstrate this problem, well some people might think it's just down to user error.

If you have genuinely found a bug in the most commonly used profiler on CPAN (and you might well have) then in the spirit of open source I would suggest to you that the very least you should do is report it. That will require a test case (an SSCCE, if you will) and the time spent to construct that should really be seen as the minuscule cost of using all this wonderful open source code to begin with.

[Nicolasd]

Relax, my personal experience won't affect the popularity of that profiler.
I am working full time on open source research, so will see when I have time.
If nobody noticed it before, I am probably not using it correctly or I am expecting something different from it.


So to clarify, if I run a script with the profiler that takes 2 minutes for example, it should point out which parts of the code take the most time
And it should not be possible that one part takes for example 10% of the real time, but the profiler doesn't picks this up (that's something I observed).

And just to confirm that I use it correct:
perl -d:NYTProf script.pl
nytprofcg
kcachegrind nytprof.callgrind