You've managed to avoid compiling the same regexps over and over again. That's good, but it's unfortunate because this common problem is easy to fix and fixing it produces great results.

Move (?{$num}) to the *end* the match. You're calling up to 8000 Perl subs when you only need to call one. (All 8000 when you need to call none if there's no match.)

Are you using Perl 5.10? If not, you should use Regexp::Assemble instead of join '|'. Both factor out common prefixes in patterns for faster matches in big alternations. This will require the change in paragraph two to kick in.

         $re{"$first$last"}||="(?{$acct})$first\\s*$last|(?{$acct})$la
+st,?\\s+$first";

         $first=substr($origfirst,0,1);
         $re2{"$first$last"}||="(?{$acct})\\b$last,?\\s+$first" 
            unless exists $hExclude->{lc $origlast} or length($last)<4
+;
[download]

         push @re, "$first\\s*$last(?{$acct})",
                   "$last,?\\s+$first(?{$acct})"
            if !$re{"$first$last"}++;

         $first=substr($origfirst,0,1);
         push @re2, "\\b$last,?\\s+$first(?{$acct})"
            if !exists($hExclude->{lc $origlast})
            && length($last)>=4;
            && !$re2{"$first$last"}++
[download]

      $re=join('|',sort ocr_sort values %re);
      $re2=join('|',sort ocr_sort values %re2);
[download]

      # 5.10.0 and higher
      $re  = join('|', sort ocr_sort @re);
      $re2 = join('|', sort ocr_sort @re2);
[download]

      # Any version of Perl
      $re = do {
         my $ra = Regexp::Assemble->new();
         $ra->add($_) for sort ocr_sort @re;
         $ra->re
      };
      $re2 = {
         my $ra = Regexp::Assemble->new();
         $ra->add($_) for sort ocr_sort @re2;
         $ra->re
      };
[download]

Very much appreciated! I never realized that the ?{} was a sub, but of course it is. I am very impressed with Regexp::Assemble. I am using 5.8.8 on the server where my app is located, but 5.10 on my laptops.

SSF

Regexp::Assemble is absolutely fantastic. I've been using it since perl 5.8.6 and it never let me down.

A quick note. Regexp::Assemble barfs on patterns containing ?{} in Perl 5.8.8 because of the error Eval-group not allowed at runtime, use re 'eval' in regex m/.../. which is inside Assemble.pm in the _build_re routine's else clause. I didn't report this as a bug because under 5.8.8 you really should use the module's tracking feature, which contains the $^R workaround. Interestingly, modifying the module (I know, I know ;-) to add the use re 'eval'; line in that else clause makes the error disappear, but the resulting regexp doesn't work. My production code finally anticipates Perl 5.10 and just joins the individual expressions with |, and with the ?{acct} at the ends like Ikegami said, and the speedup was phenomenal! It can only get better with 5.10 trie building, but I'm not quite ready to upgrade my server yet.

SSF

Apparently all your transformations are removing insignificant characters (hyphens and spaces) and taking some classes of characters as equivalent (like "i" and "j"). In this case I think you don't even need regexen. Just choose a representing character from each class, then preprocess your list of names by removing the insignificant characters and normalizing the easy to confuse characters to the representing character. For example, you'd add a column to your database where this normalized name would be stored, fill it with the names with spaces removed and all "j" replaced with "i" etc, and index on this column. Then, when you ocr a name, you just normalize it the same way and search for the normalized string in this column.

Possibly that helps with the speed, and if it does indeed, then things may become interesting. First, the regex matching the names can be then a simple concatenation of lexems like above, and second, its not necessarily that the second regex run would be needed at all, a trivial hash replacement would be enough, something along the following:

my %replace = (
 "<CL>r<ij><it><ij>a<hn>" => "Christian",
 ...
);
$text =~ s/\b(\w+)\b/exists($replace{$1}) ? $replace{$1} : $1/ge;
[download]

Again, if the alterations only consist of max 4 characters, I'm thinking that instead of composing them into "<ab>" structure, one can make them into a single unicode character f.ex. (pack("U1"), (ord("a") << 8) + ord("b")), and thus possibly gaining some extra milliseconds.

I'd suggest coding up the two and running them with Benchmark and post the results. For my problem, this wouldn't work because the OCR text is already variable, so replacing Cristian in that text would kind of be the same problem as identifying Cristian as account number 14222 in the first place.

SSF