TMTOWTDI! More than just three, that is. But basically they all boil down to do an opendir followed by a (sequence of) readdir('s). So if you're really that concerned about speed and -alleged- efficiency, then you sould go the way of explicitly doing them.

If you're actually doing globbing, though, chances are you'd better use Perl's glob a.k.a. File::Glob rather than reinventing the wheel and risking to make errors doing so. Said this...

the result does not make sence to me, but maybe you can tell me why

Well, they make sense enough to me. In the first place all times are comparable, which is fine and supports my claims above. Other than that "Way 3" seems to be slightly faster than "Way 1", but that may well be within the experimental error. As far as the former is concerned, there's still room for improvements, as you interpolate $file twice, in the map and grep: I'd just switch them:

'Way 3' => sub {
    opendir my $DIR, $folder
      or die "Error: couldn't open dir '$folder': $!\n";
    my @files = grep -f, map "$folder/$_", readdir $DIR;
    for my $file (@files) {
        # my $filename = $file; # no more need for this!
        #  print STDERR "$filename\n";
    }
}
[download]

You could also avoid assigning to @files altogether.

And as far as glob goes, there are too many unknown parameters involved, since it must do regexp matching. I don't know if it also does special optimizations for particular patterns, but chances are that it may depend on the actual filenames: as I said, far too many parameters!

Whatever, your benchmarks are bound to be imprecise. I don't know under Windows, but under Linux certainly and I believe under most unices the kernel keeps data in memory to avoid doing relatively slow disk reads and writes, which is why sync exists. One more reason, IMHO, not to bother at all!