IMHO, yes. The for version doesn't build a (possibly huge) list of the form ("x",1,"y",1,...) and then populate the hash; it just populates the hash. I suspect my "slice" version is the fastest... and:

use Benchmark;
@arr=('file.html')x1024;
timethese( -3, {
    'Slice' => '%x=();@x{@arr}=(1)x@arr',
    'For' => '%x=();for(@arr){$x{$_}=1}',
    'Map' => '%x=map{$_=>1}@arr'
} );
__END__
Benchmark: running For, Map, Slice, each for at least 3 CPU seconds...
   For: 3 secs (3.13 usr + 0.00 sys = 3.13 CPU) @ 707.72/s (n=2218)
   Map: 3 secs (3.14 usr + 0.00 sys = 3.14 CPU) @ 96.98/s (n=305)
 Slice: 4 secs (3.14 usr + 0.00 sys = 3.14 CPU) @ 1074.72/s (n=3380)
[download]

...it is (for at least one case). So "slice" is 50% faster than "for" which is much faster than "map" (with tilly's patch, "map" will probably still be slower than the others, but not nearly that slow).

Cool, code was updated.

BTW, i was suspecting that your benchmark was wrong since you used the same value in the hash (file.html). A quick check showed that it doesn't matter much. Interesting.

This is your code with @arr replaced with @ARGV. The directory has 336 files. (Also, -3 didn't work for me here)

>./benchnom *
Benchmark: timing 5000 iterations of For, Map, Slice...
       For: 10 secs ( 9.94 usr  0.00 sys =  9.94 cpu)
       Map: 21 secs (21.26 usr  0.00 sys = 21.26 cpu)
     Slice:  8 secs ( 7.27 usr  0.00 sys =  7.27 cpu)
38.57u 0.05s 0:38.88 99.3%
> ls -l | wc -l
     336
>perl -v

This is perl, version 5.004_04 built for sun4-solaris
[download]

Similar results were for perl 5.5