I tested this idea out with this code.

#!/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]

Using 1000 iterations in the loop, the results I got were...

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]

So it looks like there was some performance gain in that example using the stored var instead of directly accessing the hash value. I would guess that the second loop was faster because the application didn't have to search through a hash for the value, but someone else who has a better idea of the internal workings of Perl might be able to tell you more.
Personally, if I'm using a lot of environment variables, I like to assign them to variable names so I can assign them a name I want and not have to worry about typing $ENV{FOO} again and again.
Rich36

---

There's more than one way to screw it up...

---