A few questions

1. Why is this table in the root node?
2. Why put the original, superceded Xor in that table and not the original Trie?
3. Why the arbitrary 100 second cutoff?
4. Why not show the build time for the DFA solution--which isn't required by any of the other solutions in the table.
5. What is the procedure for updating the OP to include data from improved, corrected implementations?
6. Where are the memory consumption statistics?
7. Why is the test harness so horribly complicated?

   I have a file of things to search, and file of things to search for, a fuzziness number.

   fsearch( \*$haystacks, \*$needles, $fuzz, \*output );
   [download]

   Or, I have this array of strings to search, and this array of keys to search for, at this level of fuzziness.

   my @results = fsearch( \@haystacks, \@needles, $fuzz );
   [download]

   This is inherently a functional interface. All the rest is cruft.

Needless to say, I think the test methodology is flawed. 533 lines of code to do

use Benchmark qw[ cmpthese ];

cmpthese 1, \%tests;
[download]

More importantly, the selective presentation of statistics in the root node of the "shootout", comparing old, first-cut code, written in an hour and long since improved and superceded; with code hand crafted, in C over a 10 days, using someone else brilliant, original idea, has devalued this exercise completely.