Re^2: Clocking Portion of Your Perl Code

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.

Comment on Re^2: Clocking Portion of Your Perl Code

Replies are listed 'Best First'.
Re^3: Clocking Portion of Your Perl Code by Anonymous Monk on Jun 12, 2005 at 16:02 UTC
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.	[reply]
Re^4: Clocking Portion of Your Perl Code by salva (Canon) on Jun 12, 2005 at 18:47 UTC
You can usually trust Benchmark (I don't know about Benchmark::Timer)... but it's not perfect either: Benchmark.pm: Does subroutine testing order bias results? Sometimes, timing the full program (or a script specially written for the ocasion) from the shell with `time` is also a good solution.	[reply] [d/l]