Description
Is your feature request related to a problem? Please describe.
I notice time and again that QnAmaker tends to be... a bit slow for my tastes, especially in the small scale that I work with which doesn't justify a bigger setup. While reading about functools
's lru_cache
decorator, I got the idea of adding a cache to the QnAmaker queries.
Describe the solution you'd like
Some way to optionally activate caching when instantiating a QnAMaker
object (or QnAMakerDialog
), and have it work transparently. A nice option would be to be able to use an external cache (redis for example), so it persist beyond a particular instance of the bot.
Describe alternatives you've considered
Memorization is not easily implementable since QnAMaker.get_answers()
takes a TurnContext
object.
Additional context
I've checked the sources and couldn't find anything of this nature.
This feature should not be turned on by default, since it would break any logging/metrics/statistics that assume no caching on the bot, and caching in general can hide other issues.