The benchmark below uses his code(modified), and demonstrates that there is considerable overhead to using %ENV (I hope I did it right).

Check it out (readmore)

 

______crazyinsomniac_____________________________ Of all the things I've lost, I miss my mind the most. perl -e "$q=$_;map({chr unpack qq;H*;,$_}split(q;;,q*H*));print;$q/$q;"

On most systems there will be a signifigant performance overhead from using %ENV rather then a "normal" variable. %ENV access a system dependent table, which is typically not designed for efficient access. (On UNIX, for example, the environment table is (usually, at least) stored as an unordered, C-style, null-terminated array of strings in the format "KEY=VALUE". Searching through this to find an element is not very efficient, obviously.) Unless you need to interface with C code that uses environment variables or want to pass things to your child processes or recieve things from parent processes, you probably shouldn't use %ENV.

There are two other considerations here that have nothing to do with speed and which contradict one another:

• Do you really want your entire program to know that a certain setting is picked up from the environment? I usually view the environment as a configuration type interface: Load from it once only so I can change the source of a setting later if needed.
• On the opposite side: If a value is known to be environmental, can any other parts of the program (e.g., used packages) set it? If so, then taking it once may have the wrong effect if someone tries to set it later, expecting that later setting to have some effect.

These are mostly maintenance/large program considerations. So if this is a simple script, you can probably disregard them as factors. For large systems I tend to take the approach that hides data sources and manipulations the most since it makes longer term changes easier.

#!/usr/bin/perl -w
use strict;
use Benchmark;

{
    # Start the benchmark
    my $start = new Benchmark;

    for(1..1000) {
        print qq($ENV{PATH}\n);    
    }
    # End the program and return the Benchmark time
    my $end = new Benchmark;

    print "Processing time was...\n";
    print timestr(timediff($end, $start)) . "\n";
}
    sleep 10;
{
    my $foo = $ENV{PATH};

    # Start the benchmark
    my $start = new Benchmark;

    for(1..1000) {
        print qq($foo\n);    
    }
    # End the program and return the Benchmark time
    my $end = new Benchmark;

    print "Processing time was...\n";
    print timestr(timediff($end, $start)) . "\n";
}
[download]

Loop using $ENV{PATH}: 12 wallclock secs ( 0.13 usr +  0.15 sys =  0.2
+8 CPU)
Loop using $foo: 11 wallclock secs ( 0.07 usr +  0.05 sys =  0.12 CPU)
[download]

It definitely depends on the OS platform on which you are running, as this is where %ENV happens. It is behaving as a tied hash, hence slower than a real hash as extra bits of code are being called.

A lot depends on the implementation, and this may be quirky due to how the operating system handles environments.

See the vmsperl@perl.org mailing list archives for some examples of this.

Thanks all for the input it is appreciated. (especially as the question was so hastily/poorly written -- sorry 'bout that)

This is a heavily used set of scripts by diverse teams. While performance is not critical I like to do what I can to stay streamlined. It's dependence on $ENV has to do with its evolution from a family of ksh scripts that utilize about 30 environmental variables to control their functionality. I'm waying the pro's and cons of 'speed' to the production floor vrs code cleanliness and performance.

Me thinks I should just wipe 'em all out though that will definately add more to the time curve.

Thanks again,