in reply to Benchmark.pm's scoping behavior

You're confusing package globals and lexical variables. You wrote this code to demonstrate that you can see package variables in package R: 
    package R;
    my $R = 10;

    package main;
    my $subcode = "sub { local \$_; package R; print $R}";
    my $subref  = eval $subcode;
    &$subref;

[download]
That's not doing what you think it's doing. That code is accessing $R not because you've specified "package R" but because $R is lexically-scoped to the containing file. If you had been running your quasi-benchmark code in a different file, it wouldn't have worked. That's why, in your original code, the benchmarked code couldn't access $now and %url when you declared them with my: because they were declared lexical to the enclosing file, and your code was running in a different file.

That's why you need to make your variables package globals, presumably using the vars pragma, but probably you could also use our, in Perl 5.6. Because those package globals are in your package's namespace, so when Benchmark executes your code in the "caller's package", it's accessing the correct variables.

As for your other question: 

    > P.P.S. Here are my results with the correct code. Grep is
    > still faster than the other algorithms, so the original
    > question still stands (how can Perl execute an O(N) plus
    > an O(N log N) algorithm faster than a single O(N)?)

[download]
I don't know, but I think lhoward had the best suggestion: the sort may be O(N log N), but that's not the only measure of efficiency; how you code the algorithm, and how it's optimized, is also a big influence on speed. So running an O(N log N) algorithm in tight C code could still be faster than running an O(N) algorithm written in Perl.

Replies are listed 'Best First'.
RE:(2) Benchmark.pm's scoping behavior
by Russ (Deacon) on Jun 21, 2000 at 10:51 UTC
    I see.

    You're right, I had been confused about lexical scope. I assumed a lexical was scoped to its package, but it is actually scoped to its enclosing block (in this case, the file).

    Between your explanation and chromatic's (below), this is a great discussion!

    So, I went to my Perl books to try to find this explanation (to see which sections I have apparently never read). Camel Page 107-108:

    ...lexically scoped declarations have an effect only from the point of the declaration to the end of the innermost enclosing block. ... But a package declaration merely declares the identity of the default package for the rest of the enclosing block.
    Well, there it is. Packages do not define a namespace for lexical variables, because they do not define an enclosing block.

    I believed, in my code, that lexical variables were "scoped" to their package. (I almost *never* use global variables... package globals or otherwise. Without my habit of mying every variable, I would not have stumbled across this (and lost an opportunity to learn even more)) :-)

    All of a sudden, my version of reality is being updated. ;-)

    I agree about my other question. grep and sort are obviously highly optimized. The coolest thing is, I haven't been able to find a crossover point (where sort grep become slower than max). No matter how large the data set, and no matter how many elements must be sorted, it is still faster to do the sort algorithm than max. It should be amazing, but this is Perl, where miracles are commonplace... :-)

    Russ

[reply]

In Section Seekers of Perl Wisdom