Caching slow sources?

[madduck]

Hello, I am dealing with a slow source (cmp-lbdb via blink.compat). As a consequence, completion is mostly useless as it takes 3–4 seconds for the pop-up to pop up.

This made me wonder: could blink.cmp learn/be taught to cache results provided by sources? I envision a configuration item per source/provider that takes an integer to specify the number of seconds to hold the results in memory.

What do you think about this idea?

[soifou]

Have you tried the async property as mentioned in the doc? https://cmp.saghen.dev/configuration/sources.html#provider-options

[madduck]

Have you tried the async property as mentioned in the doc? https://cmp.saghen.dev/configuration/sources.html#provider-options

Yeah, I am using that. But it still takes a few seconds each time for results to become usable.

[Shougo]

That's an interesting feature, but what kind of specifications are you envisioning for it? When is the cache for the completion results expected to be updated?

[madduck]

That's an interesting feature, but what kind of specifications are you envisioning for it? When is the cache for the completion results expected to be updated?

I am unsure about the underlying design, and maybe I don't want to have this setting be a provider-setting, but instead more a module-level thing, but the underlying idea is the same, e.g.:

… opts = {
 sources = {
  providers = {
   lbdb = {
        …
      }
    }
  }
  cache = {
    maxage = 5
    lbdb = { maxage: 300 }
  }
}

… or somesuch… basically all provider return data would be stored in memory along with a timestamp, and when the data are queried again, then the provider would only be asked if the timestamp is more than maxage seconds in the past, in which case the return data would be fetched from the provider, and stored in cache again, along with the current timestamp.

[Shougo]

I am unsure about the underlying design, and maybe I don't want to have this setting be a provider-setting, but instead more a module-level thing, but the underlying idea is the same, e.g.:

I think the provider-setting is not bad design. What is the problem?

[madduck]

I think the provider-setting is not bad design. What is the problem?

This should probably be implemented on the top-most level and be available for all providers, rather than any sort of provider-specific implementation.

Now, if provider-setting doesn't prevent this, then yeah, probably best per-provider. I imagine it's like async actually, which is also handled by the module for all providers, just like cache should be.

[Shougo]

I get it. The feature should be implemented in the core instead of providers specific implementation.

[Saghen]

I think this is niche enough that it should be implemented by the source directly instead of by blink.cmp. You could implement this yourself using the overrides field like so:

sources = {
  providers = {
    lbdb = {
      overrides = {
        get_completions = function(source, ctx, callback)
          if check_if_cached_value_is_valid() then
            callback(cached_response)
            return
          end

          return source:get_completions(ctx, function(response)
            cached_response = response
            callback(response)
          end)
        end
      }
    }
  }
}