Are there reasons why FTSearch would not be a suitable alternative to DBColumn in a Type-Ahead on an XPage, when trying to improve...

Are there reasons why FTSearch would not be a suitable alternative to
DBColumn in a Type-Ahead on an XPage, when trying to improve...

I have a general requirement in my current project to make an existing
XPage application faster. One thing we looked at was how to speed up some
slower type-ahead fields, and one solution to this which seems to be fast,
is implementing it using FTSearch rather than the DBColumn we originally
had. I want to get advice on whether this would be an OK approach, or if
there are any suggestions to do what we need in a different way.
Background: While there are a number of factors affecting the speed (like
network latency, server OS, available server memory etc.), as we are using
8.5.3, we have optimized the application in general as far as we can,
making use of the IBM Toolkit to find problem areas, and also using the
features IBM added to help with this in 8.5.3 (e.g. Partial Execution,
using the optimized JS and CSS option, etc.). Unfortunately we are stuck
with the server running on a 32bit Windows OS with 3.5MB Ram for another
few months.
One of the slowest elements to respond are in certain type-aheads which
reference a large number of documents. The worst one averages around 5 or
6 seconds before the suggested list appears for a type-ahead enabled
field. It uses SSJS to call a java class to perform a dbcolumn call (using
Ferry Kranenburg's XPages Snippet) to get a unique list from a view, then
back in SSJS it loops though the array to check if each entry contains the
search key value, and if found it adds a highlight (bold) html tag around
the search text in the word, then returns the formatted list back to the
browser. I added a print statement to output the elapsed time it takes to
run the code, and on average today on our dev server it is around 3250 ms.
I tried a few things to see how we could make this process faster:
Added a Java class to do all processing (so not using SSJS). This only
saved an average of 100ms.
Using a view-scoped Managed Bean, I loaded the unique Lookup list into
memory when the page is loaded. This produces a really fast type-ahead
response (16ms), but I suspect this is a very bad way to do this with a
large data set - and could really impact the general server if multiple
users were accessing the application. I tried to find information on what
would be considered a large object, but couldn't find any guidance or
recommendation on how much is too much to store in memory (I searched JSF
and XPage sites). Does anyone have any suggestions on this?
Still in a Java class - instead of performing a dblookup to get the 'list'
of all values to search through, I have the code run a FT Search to get
the doc collection, then loop each doc to extract the field value I want
and add those to a 'SortedSet' (which automatically doesn't allow
duplicates), then loop the sorted set to insert the bold tags around the
search term, and return that to the browser. This takes on average 100ms -
which is great and barely noticeable. Are there an drawbacks to this
approach - or reasons I should not do it this way?
Thanks for any feedback or advice on this. Pam.