in reply to Re^3: Yet Another "Matching over a list of conditions"-like technique
in thread Yet Another "Matching over a list of conditions"-like technique

i.e. use some trick to let the "most probable" choice be the first one to be tested.
In that case I'd bubble single elements to the top. That retains memory of second-, third-, etc most likely matches based on previous data. Depending on the patterns in your data that may or may not be more, less or equally efficient.
<snip code>
I'm too lazy to set up a test environment to benchmark this, sorry. Depending on how much the array lookup costs it might pay to maintain the counter explicitly as you did in your code, though I can't quite believe that.
Well, first of all I may silently avoid to mention this detail, but... to be honest the benchmark of the previous post is not correct for, briefly speaking '../../pics/' was wrong, so that C<-e> never succeeded. I did the test again with the code attached at the end of this post. Here's what I get: I notice that my solution is still slightly more efficient than yours both in 'regular' and 'extremely adverse' conditions whereas it is outperformed by yours in the second case. I wonder if that may be due to the 'history' approach of your new version of the snippet...

UPDATE: Indeed I did some more experiments and I noticed that it is definitely so. Not to clobber too much the original text here I've added the new results below, at 'UPDATED RESULTS'.

Note that in your case, a chdir '../../pics/' might speed things up quite a bit if you're testing a lot of files, since stat(2) won't have to traverse the same directories over and over for each and every single file test.
I am aware of this. Of course this was originally a quick hack. The data set I'm testing this against is a realistic one and the times involved are those shown above, so that I'm not really that mad about performance. As I wrote repeatedly this was meant more of an illustrative example than the definitive word on this issue: in another situation it may apply to the frequently asked question about how to match against a list of regexen or something similar...

Here's the code: 

#!/usr/bin/perl

use strict;
use warnings;
use Benchmark qw/:all :hireswallclock/;

my @ARGV0=@ARGV;
my @pre=map "pics/$_/", '00'..'16';

cmpthese 1000, { blazar => \&blazar,
                 aristotle =>\&aristotle }, 'all';

sub blazar {
    @ARGV=@ARGV0;
    while (<>) {
        chomp;
        my $cnt;
        for my $p (@pre) {
            local $_ = $p . $_;
            if (-e) {
                # print;
                push @pre, splice @pre, 0, $cnt if $cnt;
                last;
            }
            $cnt++;
        }
    } 
}

sub aristotle {
    @ARGV=@ARGV0;
    while ( <> ) {
        chomp;
        for my $i ( 0 .. $#pre ) {
            local $_ = $pre[ $i ] . $_;
            next if not -e;
            # print;
            @pre[ 0 .. $i ] = @pre[ $i, 0 .. $i - 1 ] if $i;
            last;
        }
    }
}

__END__

[download]

UPDATED RESULTS

Due to the observation above I modified my sub, now the only difference with Aristotle's one is that I iterate over the array and maintain a counter manually (what that incidentally he considers to be surprisingly annoying to follow) whereas he iterates over indices. I also included a "naive" sub for comparison; the tested subs are now as follows: 
sub blazar {
    @ARGV=@ARGV0;
    while (<>) {
        chomp;
        my $cnt;
        for my $p (@pre) {
            local $_ = $p . $_;
            if (-e) {
                # print;
                @pre[0..$cnt] = @pre[$cnt,0..$cnt-1] if $cnt;
                last;
            }
            $cnt++;
        }
    } 
}

sub aristotle {
    @ARGV=@ARGV0;
    while ( <> ) {
        chomp;
        for my $i ( 0 .. $#pre ) {
            local $_ = $pre[ $i ] . $_;
            next if not -e;
            # print;
            @pre[ 0 .. $i ] = @pre[ $i, 0 .. $i - 1 ] if $i;
            last;
        }
    }
}

sub naive {
    @ARGV=@ARGV0;
    while (<>) {
        chomp;
        for my $p (@pre) {
            local $_ = $p . $_;
            # print,
              last if -e;
        }
    } 
}

[download]
The results are: I also tried it on the three lists all at a time, and while I do not consider this result to be terribly indicative, still I find it encouraging: 
Benchmark: timing 1000 iterations of aristotle, blazar, naive...
 aristotle: 39.3629 wallclock secs (18.54 usr 20.81 sys +  0.00 cusr  0.00 csys
= 39.35 CPU) @ 25.41/s (n=1000)
    blazar: 37.3122 wallclock secs (16.47 usr 20.84 sys +  0.00 cusr  0.00 csys
= 37.31 CPU) @ 26.80/s (n=1000)
     naive: 38.9548 wallclock secs (15.16 usr 23.79 sys +  0.00 cusr  0.00 csys
= 38.95 CPU) @ 25.67/s (n=1000)
            Rate aristotle     naive    blazar
aristotle 25.4/s        --       -1%       -5%
naive     25.7/s        1%        --       -4%
blazar    26.8/s        5%        4%        --

In Section Cool Uses for Perl