I don't fully understand how q and square brackets work in your code, even after just looking up some documentation.

Benchmark will accept a string containing a piece of code, where you normally supply a subroutine. From the synopsis:

    # Use Perl code in strings...
    timethese($count, {
        'Name1' => '...code1...',
        'Name2' => '...code2...',
    });
    # ... or use subroutine references.
    timethese($count, {
        'Name1' => sub { ...code1... },
        'Name2' => sub { ...code2... },
    });
    # cmpthese can be used both ways as well
    cmpthese($count, {
        'Name1' => '...code1...',
        'Name2' => '...code2...',
    });
    cmpthese($count, {
        'Name1' => sub { ...code1... },
        'Name2' => sub { ...code2... },
    });
[download]

That's what my example did.

What actually happens under the covers (greatly simplified) is that a call to the code reference (subroutine) that you supply to Benchmark is eval'd into another subroutine within the package that wraps that call in a loop:

    my ($subcode, $subref);
    if (ref $c eq 'CODE') {
    $subcode = "sub { for (1 .. $n) { local \$_; package $pack; &\$c; 
+} }";
        $subref  = eval $subcode;
    }
    else {
    $subcode = "sub { for (1 .. $n) { local \$_; package $pack; $c;} }
+";
        $subref  = _doeval($subcode);
    }
[download]

As you can see, if what you supply is a string rather than a code ref, that string is eval'd into that extra level of subroutine instead.

From the Benchmark docs:

CAVEATS

Comparing eval'd strings with code references will give you inaccurate results: a code reference will show a slightly slower execution time than the equivalent eval'd string.

So either use code refs, or strings, but do not mix the two. (Though in the case of our dummy sub that just forces preallocation of memory, it doesn't matter as it isn't a part of the timing.)

Ah, that makes sense now. I knew several of those pieces, but didn't put them together like you just did.

I saw that q returns a string, but was confused as to what Benchmark would do with that. But I also knew that Benchmark eval'd code in a loop. I just didn't put it all together.

Thanks for taking the time to explain that.

ysth,

++ for the good suggestion. And you can add a print statement for the *returned* results from each subroutine.

I've seen examples of 'benchmark'ing 2 subroutines that don't produce the same results. Unless the results are the same, it doesn't make sense to compare the subroutines.

Regards...Ed

"Well done is better than well said." - Benjamin Franklin

I learned that the hard way the other day. Since I don't need "exactly-the-same" results from my tests, I now normalize them and do a character count to make sure they're not too far off from each other. For what I'm doing, and at this stage of my process, that's perfectly fine.

I'm also finding, with the constant back and forth between code and running a benchmark, a want for some other features in the Benchmark module. I wrote some stuff that makes the process faster and easier. At the end of this project, I might clean it up and get it up here.

No idea why I didn't think of that, but, based ons some tests, it looks like that works. For good measure, I'm loading it twice. And it keeps me from having to guess at how large of a string to create.

Thank you.