Boyer–Moore–Horspool algorithm

<h2 id="description">Description</h2>
Like Boyer–Moore, Boyer–Moore–Horspool preprocesses the pattern to produce a table containing, for each symbol in the <a href="/facts/Alphabet_(formal_languages)/6KW9qYRW">alphabet</a>, the number of characters that can safely be skipped. The preprocessing phase, in pseudocode, is as follows (for an alphabet of 256 symbols, i.e., bytes):

 // Unlike the original, we use zero-based indices here.
 function preprocess(pattern)
 T := new table of 256 integers
 for i from 0 to 256 exclusive
 T[i] := length(pattern)
 for i from 0 to length(pattern) - 1 exclusive
 T[pattern[i]] := length(pattern) - 1 - i
 return T

Pattern search proceeds as follows. The procedure search reports the index of the first occurrence of needle in haystack.

// Compares two strings, up to the first len characters.
// Note: this is equivalent to !memcmp(str1, str2, len).
function same(str1, str2, len)
 i := len - 1
 // The original algorithm tries to play smart here: it checks for the
 // last character, then second-last, etc.
 while str1[i] == str2[i]
 if i == 0
 return true
 i := i - 1
 return false

function search(needle, haystack)
    T := preprocess(needle)
    skip := 0
    // haystack[skip:] means substring starting at index `skip`. Would be &haystack[skip] in C.
    while length(haystack) - skip >= length(needle)
        if same(haystack[skip:], needle, length(needle))
            return skip
        skip := skip + T[haystack[skip + length(needle) - 1]]
    return -1

<h2 id="performance">Performance</h2>
The algorithm performs best with long needle strings, when it consistently hits a non-matching character at or near the final byte of the current position in the haystack and the final byte of the needle does not occur elsewhere within the needle. For instance a 32 byte needle ending in "z" searching through a 255 byte haystack which does not have a 'z' byte in it would take up to 224 byte comparisons.
The best case is the same as for the Boyer–Moore string-search algorithm in <a href="/facts/Big_O_notation/weFFjSWg">big O notation</a>, although the constant overhead of initialization and for each loop is less.
The worst case behavior happens when the bad character skip is consistently low (with the lower limit of 1 byte movement) and a large portion of the needle matches the haystack. The bad character skip is only low, on a partial match, when the final character of the needle also occurs elsewhere within the needle, with 1 byte movement happening when the same byte is in both of the last two positions.
The canonical degenerate case similar to the above "best" case is a needle of an 'a' byte followed by 31 'z' bytes in a haystack consisting of 255 'z' bytes. This will do 31 successful byte comparisons, a 1 byte comparison that fails and then move forward 1 byte. This process will repeat 223 more times (255 − 32), bringing the total byte comparisons to 7,168 (32 × 224). (A different byte-comparison loop will have a different behavior.)
The worst case is significantly higher than for the Boyer–Moore string-search algorithm, although obviously this is hard to achieve in normal use cases. It is also worth noting that this worst case is also the worst case for the naive (but usual) memcmp() algorithm, although the implementation of that tends to be significantly optimized (and is more cache friendly).

<h3>Tuning the comparison loop</h3>
The original algorithm had a more sophisticated same() loop. It uses an extra pre-check before proceeding in the positive direction:<a class="footnote-ref" id="fnref:2" href="#fn:2">2</a>

function same_orig(str1, str2, len)
 i ← 0
 if str1[len - 1] = str2[len - 1]
 while str1[i] = str2[i]
 if i = len - 2
 return true
 i ← i + 1
 return false

A tuned version of the BMH algorithm is the <a href="/facts/Raita_algorithm/r17Kzthn">Raita algorithm</a>. It adds an additional precheck for the middle character, in the order of last-first-middle. The algorithm enters the full loop only when the check passes:<a class="footnote-ref" id="fnref:3" href="#fn:3">3</a>

function same_raita(str1, str2, len)
 i ← 0
 mid ← len / 2
 
 Three prechecks.
 if len ≥ 3
 if str[mid] != str2[mid]
 return false
 if len ≥ 1
 if str[0] != str2[0]
 return false
 if len ≥ 2
 if str[len - 1] != str2[len - 1]
 return false

Any old comparison loop.
 return len < 3 or SAME(&str1[1], &str2[1], len - 2)

It is unclear whether this 1992 tuning still holds its performance advantage on modern machines. The rationale by the authors is that actual text usually contains some patterns which can be effectively prefiltered by these three characters. It appears that Raita is not aware of the old last-character precheck (he believed that the backward-only same routine is the Horspool implementation), so readers are advised to take the results with a grain of salt.<a class="footnote-ref" id="fnref:4" href="#fn:4">4</a>
On modern machines, library functions like memcmp tends to provide better throughput than any of the hand-written comparison loops. The behavior of an "SFC" loop (Horspool's terminology) both in libstdc++ and libc++ seems to suggest that a modern Raita implementation should not include any of the one-character shifts, since they have detrimental effects on data alignment.<a class="footnote-ref" id="fnref:5" href="#fn:5">5</a><a class="footnote-ref" id="fnref:6" href="#fn:6">6</a> Also see <a href="/facts/String-searching_algorithm/RCvwDRle">String-searching algorithm</a> which has detailed analysis of other string searching algorithms.

<h2 id="external-links">External links</h2>
<ul><li><a href="http://www-igm.univ-mlv.fr/%7Elecroq/string/node18.html">Description of the algorithm</a></li>
<li><a href="https://chromium.googlesource.com/v8/v8.git/+/d123f30b6df5507b2acda8e85ad63e05de8ca8a7/src/string-search.h#428">An implementation from V8 JavaScript engine written in C++</a></li></ul>

<h2 id="references">References</h2>

<ol>
<li id="fn:1">Horspool, R. N. (1980). "Practical fast searching in strings". Software: Practice and Experience. 10 (6): 501–506. CiteSeerX 10.1.1.63.3421. doi:10.1002/spe.4380100608. S2CID 6618295. <a href="/wiki/Nigel_Horspool" target="_blank">/wiki/Nigel_Horspool</a> <a href="#fnref:1" class="footnote-back-ref">↩</a></li>
<li id="fn:2">Horspool, R. N. (1980). "Practical fast searching in strings". Software: Practice and Experience. 10 (6): 501–506. CiteSeerX 10.1.1.63.3421. doi:10.1002/spe.4380100608. S2CID 6618295. <a href="/wiki/Nigel_Horspool" target="_blank">/wiki/Nigel_Horspool</a> <a href="#fnref:2" class="footnote-back-ref">↩</a></li>
<li id="fn:3">Raita, Timo (1992). "Tuning the boyer-moore-horspool string searching algorithm". Software: Practice and Experience. 22 (10): 879–884. doi:10.1002/spe.4380221006. S2CID 14193323. <a href="/wiki/Doi_(identifier)" target="_blank">/wiki/Doi_(identifier)</a> <a href="#fnref:3" class="footnote-back-ref">↩</a></li>
<li id="fn:4">Raita, Timo (1992). "Tuning the boyer-moore-horspool string searching algorithm". Software: Practice and Experience. 22 (10): 879–884. doi:10.1002/spe.4380221006. S2CID 14193323. <a href="/wiki/Doi_(identifier)" target="_blank">/wiki/Doi_(identifier)</a> <a href="#fnref:4" class="footnote-back-ref">↩</a></li>
<li id="fn:5">"⚙ D27068 Improve string::find". LLVM Code Review. <a href="https://reviews.llvm.org/D27068" target="_blank">https://reviews.llvm.org/D27068</a> <a href="#fnref:5" class="footnote-back-ref">↩</a></li>
<li id="fn:6">"[PATCH] improve string find algorithm". GCC. <a href="https://gcc.gnu.org/legacy-ml/libstdc++/2017-01/msg00039.html" target="_blank">https://gcc.gnu.org/legacy-ml/libstdc++/2017-01/msg00039.html</a> <a href="#fnref:6" class="footnote-back-ref">↩</a></li>
</ol>

Boyer–Moore–Horspool algorithm open-in-new

Boyer–Moore–Horspool algorithm