The super-simple baseline referred to in the intro was whipped up as a trivial example of the simplest approach you could take for the problem.
Trie was never in contention as I didn't want to rely on any algorithms that involved pointer chasing. There's this comment at the top of StringTable.h:
The design is optimized for relatively short strings (less than or equal to
16 chars), and relatively few of them (less than or equal to 16). These
restrictive size constraints facilitate aggressive SIMD optimizations when
searching for the strings within the table, with the goal to minimize the
maximum possible latency incurred by the lookup mechanism. The trade-off
is usability and flexibility -- two things which can be better served by
prefix trees if the pointer-chasing behavior of said data structures can
be tolerated.
https://github.com/tpn/tracer/blob/v0.1.12/StringTable2/Stri...I'm not sure if Boyer-Moore is well suited to the specific use case I wanted to address. It is geared toward looking for occurrences of a pattern in a stream of text bytes, which isn't really what I'm doing at all. I have an input string of known length. I have up to 16 strings in a table, and I want to quickly check if any of those strings "start with or are equal to" my input string, with special emphasis on negative matching being on the fast path, and preserving the location of the match in the table (so it can be cast to an enum, for example).
So, this article was specifically about the SIMD-oriented STRING_TABLE structure, not necessarily about the history of string processing. Another article potentially comparing this approach to tries, Boyer-Moor or Aho-Corasick would make sense in the context of larger prefix table data sets (and a larger text corpus being searched, e.g. wikipedia dumps).