Benchmark::Timer will allow you to wrap timing code around existing code without restructuring and with little impact upon it. It will also accumulate statistics from multiple timed segments in a single run and generate the familiar Benchmark.pm style reports at the end.

Devel::SmallProf profiles code line by line instead sub by sub.

Also how do you benchmark::timer the subroutine:

my @acc_array;
foreach(@somearray){

  if($cond ==1) {
   
   my $a = Benchmark::Timer->new(skip => 0);
   $a->start('tag');
   @acc_array = &some_long_running_func($_);
   $a->stop('tag');
   print $a->report;

  }

}
[download]

Print this:

Processed: 1
tag  still running at mycode.pl line 223
Processed: 2
tag still running at mycode.pl line 223
[download]

Instead of giving the time. What's wrong with my code?

There doesn't appear to be anything wrong with your code. It would perhaps be easier to diagnose if we knew which line of your snippet was line 223?

That said, I generally create a single B::T object at the beginning of the program and the call report at the end. That allows me to time several portions of the code by using different tags.

I can't see how your use of close scoping would affect the outcome or produce the error you're seeing, but I thought I'd mention it anyway.

If you don't want to post the real code, then I think you will have to try and produce a small testcase that reproduces the behaviour before we can help you further.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

"Science is about questioning the status quo. Questioning authority".

The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.

Hi
It seems that Benchmark::Timer is what I need, but having read your comment:

with little impact upon it

I am a bit cautious. What do you mean by that? Is it harmful?

Is it harmful?

No. I simple meant that being a call interface rather than a callback interface, it dances your tune rather than you it's. You don't have to restructure everything to us it.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

"Science is about questioning the status quo. Questioning authority".

The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.

just a warning about the use of profiling modules to time things:

perl profilers work running additional perl code between every instruction and subroutine call. That introduces overhead and affects performance and timing, sometimes in a no linear fashion. What looks faster under a profiler will actually run slower in normal execution.

So, profilers are good to find hot spoots in code but not to compare different algorithms or implementations.

That introduces overhead and affects performance and timing

Dear salva,
Thanks so much for your important comment!
Does that also affect timing with Benchmark or Benchmark::Timer?
If so what's the best way to time the portion of your code without having have to add overhead.

In Benchmark module, I also mean that with 'timethese' etc method. I do have to _separate out_ the code that I want to measure the time. This is inconvenient. Is it possible to time those part without altering the overall structure of my code?

Devel::Profiler only time the code as a whole not portion of it.

I thought Benchmark is only used for "comparing" subroutines, etc. I don't recall any method in Benchmark that does stand-alone time measurement.

Check these methods in Benchmark:

timethis
timeit
countit
[download]

Regards,
Edward

#!/usr/bin/perl -w

use Benchmark;

my $start_time = new Benchmark;

$line++ while (<>);   # Count number of lines in the file(s)

my $end_time = new Benchmark;
my $difference = timediff($end_time, $start_time);

print ("Counted $line lines\n");
print ("It took ", timestr($difference), "\n");
[download]

[sk]% bench *.csv

Counted 900285 lines
It took  2 wallclock secs ( 1.88 usr +  0.27 sys =  2.15 CPU)
[download]

Hi,
THanks for the reply.

>It took 2 wallclock secs ( 1.88 usr + 0.27 sys = 2.15 CPU)

What's the difference between these three:


wallclock
usr
sys
[download]

In short, the wallclock time elapsed is the real (actual) time that passed during the execution of your program. The CPU time is the time it took for the CPU to execute the program, taking into account the fact that your program may not be the only thing running at the moment, so that more or less this is independent of the load on your system. CPU time is further broken down into time used for system calls and time spent actually in your code.

Using the time Command to Measure CPU Use, despite being a guide for AIX users, has a pretty good explanation as well.