By implementing the max_word_length vs total_length optimizations, the time taken to process large auto-link sets is reduced by roughly 10%. By storing these values in the page list itself, rather than compiling them at runtime, the time taken for auto-links is reduced dramatically (about 70% overall).
In a test with a list of 14,000 possible titles, the original process took between .25 and .40 seconds on an average-length test page (varying by cache hits/misses and server load). Scaling linearly, this suggests that since applying the recent memory optimization to the page list, 100K would take 1.8-2.8 seconds. By adding a number of optimizations (removing unnecessary function calls, reordering conditionals, calculating max_word_length in the page vs max_word_length of each title vs max_length of each title and storing those values in the page/page list), the same test took between .06-.08 seconds to complete. I have not tested on a full 100,000 list, but this test seems to suggest that 100K would now only take 0.5-0.65 seconds. Since these tests were only performed on a single page, it is unclear what the results would be for a forum thread with 20 posts per page (it's likely the time would be nearly 20x, but it is highly dependent on the number of characters in the content processed).
Of course, auto-link output is saved in the post cache, so this only matters for an unprimed cache.
I will begin looking at the reverse lookup variant now to see if that actually leads to improvement, and if so, that the improvement exceeds the max_word optimization for at least a subset of list sizes vs content length. max_word only applies when doing direct matching of every item in the page list.