Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic

Re^2: Efficiency of map vs. more verbose basic/fundamental code

by marquezc329 (Scribe)
on Oct 05, 2012 at 03:56 UTC ( #997370=note: print w/replies, xml ) Need Help??

in reply to Re: Efficiency of map vs. more verbose basic/fundamental code
in thread Efficiency of map vs. more verbose basic/fundamental code

Can you explain what you mean by "apples to apples"? You're not the first to mention it. I honestly have never run a benchmark before and did it on the code that was in the passage only to test the statement the author made about the comparative efficiency.
I was thinking that if both pieces of code did the exact same thing and I benchmarked them I could figure out if speed was being sacrificed by the use of the more brief coding technique. BrowserUk explained that the speed on this particular operation was trivial, but the sacrifice could potentially be in memory if we were to apply this procedure on a larger scale. So I thought I had my answer. Am I approaching this problem in the wrong way? In this case what are my apples and oranges and how would I go about doing a proper benchmark? I apologize if I'm asking too many questions.
  • Comment on Re^2: Efficiency of map vs. more verbose basic/fundamental code

Replies are listed 'Best First'.
Re^3: Efficiency of map vs. more verbose basic/fundamental code
by aaron_baugher (Curate) on Oct 05, 2012 at 12:07 UTC

    Two important things in running a benchmark are:

    1) Make sure your subroutines are doing the same thing with the same data. I made the mistake once of setting up the data outside the subroutine and then editing it in place, so that the second routine to run was working with different data than the first. Make sure each one starts with the same thing and has the same result.

    2) Avoid anything that adds overhead which could overshadow the time used by the function that you're actually trying to benchmark. If you're comparing for and map, just include them and as little else as possible. Especially avoid any system calls, IO like printing, etc. Print the results once to make sure your outputs match, but then remove those statements. A difference of nanoseconds won't show through the random noise if you're calling functions that take milliseconds.

    Aaron B.
    Available for small or large Perl jobs; see my home node.

      I like this answer.
      In recent Perl, a "for" and a "map" statement will be almost identical in performance.

      Disk I/O statements especially can confuse benchmarks. That is because the Disk/File System has caching algorithms. I have one program that takes 7 seconds for the first search. The subsequent searches take like <1 second.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://997370]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others chanting in the Monastery: (4)
As of 2018-06-18 04:24 GMT
Find Nodes?
    Voting Booth?
    Should cpanminus be part of the standard Perl release?

    Results (107 votes). Check out past polls.