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 reply to Re^4: Yet Another "Matching over a list of conditions"-like technique by blazar
in thread Yet Another "Matching over a list of conditions"-like technique by blazar

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.