Claims of "blazingly fast" should be backed up with publicly reproducible data. My private benchmarks have Frederik Hertzum's Iosovitch 2X faster than the next fastest implementation, and my addition of some standard mathematical optimizations improved it by another 2X.

A new branch should be created to contain reproducible benchmark code for a variety of common implementations, including the implementation found in python-Levenshtein, and the Levenshtein automata implementation in fst (a rust implementation).

A typical use case is to query a database for the best match, that is, for the match with minimum edit distance. In such a case, the maximum edit distance k used for early bailout can decrease to the minimum edit distance seen so far as the query is running. If the provided maximum distance is k=7 and the minimum edit distance seen so far is 2, there is no point in computing distances up to k=7 for the next 98,000 rows.

The Wagner-Fischer algorithm uses a matrix that is easily small enough to fit into an AVX2 register for many applications. An algorithm using AVX2 instructions would be interesting. However, it's not clear that we would see significant performance gains over the current optimized serial algorithm. I speculate that, at this point, there is more time spent in overhead than there is spent computing the edit distance.

The function names weren't being exported, so I had to add __declspec(dllexport) and __cdecl to each function declaration in the extern "C" {} groups, in each class. Then I compiled under Visual Studio, and everything worked.

Originally posted by @ebaldino in #8 (comment)

I don't have access to this platform to implement this fix, but it should be pretty simple! I welcome pull requests. Also see issue #2.

Having issue on centos 7

"Can't open shared library 'libdamlev.so' (errno: 11, /lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by /usr/lib64/mysql/plugin/libdamlev.so))"

The Windows build process can be described as, "Just do whatever to get the .dll." I couldn't get Visual Studio 2019 EAP to build the library via CMake, so I created a Visual Studio project in which the MySQL include and plugin directories are hardcoded to my own machine. The CMakeLists.txt file includes a half-hearted attempt at facilitating a build on Windows, but it's probably better to remove that code and wait for someone to do it right than to leave it in there.

I'm getting this error when trying to install the functions:

ERROR 1127 (HY000): Can't find symbol 'DAMLEV' in library

I'm surprised nobody posted this issue until now. Tried with two different ubuntu server installations all meeting the requirements and the error is still the same.

When I execute through mysql this command: SHOW VARIABLES LIKE '%plugin%' the plugin directory is /usr/lib/mysql/plugin... but when I execute the command mysql_config --plugindir, the directory is this one /usr/lib/x86_64-linux-gnu/mariadb18/plugin. Anyway, I installed the libdamlev.so file in both directories just in case.

What I am doing wrong? MySQL version is 8.0.17

Just spend some hours to get in working, then the firs test failed.
Looks like the logic is not a real Damerau-distance, e.g.

• ABC vs ABD gives distance 1 => correct
• Haupt vs Hautp gives distance 2 => should be 1 only since Damerau counts swaped chars as 1 operation, not 2

Another, correct implementation shows distance correctly:

CREATE FUNCTION damlev RETURNS INTEGER
SONAME 'libdamlev.dll'

1127 - Can't find symbol 'damlev' in library
Time: 0,004s

does not find any

If you are having trouble compiling-- try getting rid of everything under ### Testing and Benchmarking ### in CMakeLists.txt that way you don't have to download the large boost library (boost isn't clearly listed as a requirement)

Originally posted by @sjlevy in #6 (comment)

Figure out what we're using boost for. Either replace it with a lighter alternative, remove the dependency altogether, or, if it's absolutely necessary, document the dependency and its consequences.