Кстати, сфера применения нашего алгоритма мультипоиска достаточно очевидна из второго алгоритма: разбор всяких потоков данных. Т.е. ясно ограничение на длину и количество искомых слов.
Грешно тут переделывать под оптимизацию

Вообще, я сейчас придерживаюсь принципа оптимизации, для нагруженных приложений: определяющей является работа с памятью (в широком смысле, например, форматы данных и проч.), а не заоптимизированное программирование алгоритмов. Какой-нибудь XML там, где он не нужен, может съедать до 70% маш. времени. Если же XML приходит извне и неизбежен, то при простом формате избегание использования общих парсеров типа DOM, замусоривающих память динамическими объектами, даёт тоже приличный эффект.
И так по всей программе: перестать в каком-нибудь месте "мусорить" и нагружать сборщик - значительно более приличная оптимизация, чем перестановка буков в алгоритме. (При использовании КП есть много путей повышения эффективности. В отличие от Java, где вы даже строчку не заведёте без выделения дин. памяти. Теперь, конечно, есть JIT-оптимизаторы, перекидывающие эту работу обратно на стек... но ну её в качель, всю эту чунгу-чангу).

К тому же алгоритм оптимизировать можно всегда "задним числом", а вот переделать работу с памятью без глубокой переделки часто нельзя.