Если в стеке хранить то ещё не очень плохо. Если массив где-то далеко в куче, то локальность ухудшается, а это плохо, ну там у кэша вроде всего несколько блоков-окошек в память, которые сплошные.
В любом случае таблица вряд ли превысит четверть размера кэша L2 (обычно 256К/4=64К), т.е. вся таблица займёт не более одного из четырёх ассоциативных блока. Второй блок на стек, третий и четвёртый на исходные строки, если переменные будут в регистрах, то больше обращений в память и не надо (на время сравнения строк). Собственно стек и не нужен во время сравнения строк, так что один блок кэша можно оставить на локальные переменные в памяти. Хватает, замедления не будет.
-- 16.05.2019, 17:03 --Оптимизировать сравнение Unicode строк вообще считаю бессмысленно, т.к. там 95% времени будет получение кода каждого символа и лишь <5% займут все операции сравнения строк. Unicode символы мало того что не помещаются даже в short (16 битов), так они даже в int (32 бита) могут не поместиться - если будут комбинированными (из нескольких кодов), а не базовыми (из одного кода). И если чуть более миллиона базовых кодов ещё можно уместить в табличку, то с комбинированными табличка распухает неприлично. Конечно если делать "максимально универсально", а не ограничиться например сравнением лишь русского и английского алфавитов.
