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

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.

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

Replies are listed 'Best First'.
Re^10: System call doesn't work when there is a large amount of data in a hash by Nicolasd (Acolyte) on May 01, 2020 at 23:12 UTC
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	[reply]

Replies are listed 'Best First'.

Re^10: System call doesn't work when there is a large amount of data in a hash
by Nicolasd (Acolyte) on May 01, 2020 at 23:12 UTC

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

[reply]