Did You Mean optimization fails for some data sets

Branch is available here for testing:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp-1931162-DYM-optimization / user/miker/lp-1931162-DYM-optimization

From the commit:

For some data sets and some queries the Did You Mean search suggestion logic can be much too slow. This is mainly in cases where a "misspelled" word of sufficient length greater than the symspell prefix length is checked against many short prefixes that have many long suggestions attached to them.

This commit optimizes for that case in particular by testing the length of suggestions and prefix keys against the user input to avoid unnecessary tests. Futher, it captures the edit distance of suggestions that pass that test in-line, avoiding expensive retesting, and caches the short-cutoff edit distance when in low-verbosity mode to avoid future different-but-not-too-different suggestions coming from the same prefix key.

It additionally provides a general optimization by batching the capture of suggest counts to avoid per-suggestion secondary lookups, and a micro-optimization of ordering suggestions by length at distance cache time.

What would be a suggested mode to test this on the Concerto dataset?

Hi Shula,

Unfortunately for testing purposes, Concerto is not big enough to trigger the optimization issues that this commit addresses. We have tested it locally on a large consortial data set, and it does what it says on the tin for us, without any additional code or configuration tuning.

If you can independently confirm that it does not /break/ anything, that would be a big help.

Thanks!

Tested multiple searches across Concerto and nothing broke.

I sign off on this patch with my name, Shula Link, and my email, <email address hidden>.

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=commit;h=96f05bd08b1ce77dc748b2d20e8340682bf89087

Works well for me also, pushed to master and rel_3_7. Thanks Mike and Shula!