in reply to Re: Algorithm Efficiency vs. Specialized Hardware?
in thread Algorithm Efficiency vs. Specialized Hardware?

aighearach, I saw the same thing, but forgot to post anything about it. Thank you.

I wonder about this as well. I suspected it was the profiler causing the extra overhead, but your results show it happening with just Benchmark. I have run it this way myself and found similar results.

This is funny. I "preach" to co-workers to forget their 'C' days, and ignore performance. "Perl is about programmer efficiency, not CPU efficiency," I say. Now, I am fascinated with this discussion, which is all about esoteric trivia of Perl efficiency.

:-)

Russ

  • Comment on RE:(2) Algorithm Efficiency (function overhead)

Replies are listed 'Best First'.
RE: RE:(2) Algorithm Efficiency (function overhead)
by btrott (Parson) on Jun 21, 2000 at 00:53 UTC
    No, it's not the extra weight of the subroutine calls, although sub calls do cause more overhead. What's causing this is what I mentioned earlier: you have scoping problems. None of the code you're benchmarking is actually using a valid value for either %url or $now. So your results are completely bogus.

    The valid results are those that use a properly scoped variable. Aighearach's code did this, though I'm not sure it did so intentionally.

    You can accomplish this by declaring your vars as package globals:

    use vars qw/$now %url/; $now = 8; %url = ( monday => { @{[map(($_,1), (1..1000))]} } );
    This gives valid results.
    Benchmark: timing 1000 iterations of Grep, Max, Ternary... Grep: 6 wallclock secs ( 5.49 usr + 0.00 sys = 5.49 CPU) Max: 5 wallclock secs ( 5.81 usr + 0.00 sys = 5.81 CPU) Ternary: 7 wallclock secs ( 6.42 usr + 0.00 sys = 6.42 CPU)