[bug#39258] Faster guix search using an sqlite cache

["Ludovic Courtès" <ludo@gnu.org>]

zimoun <zimon.toutoune@gmail.com> skribis:

> On Tue, 11 Feb 2020 at 17:29, Ludovic Courtès <ludo@gnu.org> wrote:
>
>> I would rather keep the current package cache as-is instead of inserting
>> sqlite in here.  I don’t expect it to bring much compared
>> performance-wise to the current simple cache (especially if we look at
>> load time), and it does increase complexity quite a bit.
>
> Complexity is about taste. ;-)

It’s measurable to some extent (lines of code, cyclomatic complexity,
etc.)

> About performance, the idea was to first implement something with
> sqlite and then see if it makes the difference. I mean I have
> understood that.

Yes.  But keep in mind that this package cache is used exclusively for
package lookups by name.  Namely, the goal is to speed package lookup in
operations like “guix install foo” (mapping “foo” to the right <package>
in the right module without walking through all the modules) and “guix
package -A” (which is what the shell completion hooks use).

Currently “guix package -A” runs in .5s on my laptop, and I suspect it’s
going to be hard to do better just by touching the cache.

>> However, using sqlite for keyword search as you initially proposed on
>> guix-devel does sound like a great idea to me.
>
> If I understand correctly, you are proposing 2 caches, right?
> Or are you proposing an inverted index (VHash/VList table) based on
> trigrams to speed up the lookup?

Arun started the discussion on guix-devel with the idea of an inverted
index, and I thought this would become a second index (possibly
implemented using SQLite).  Perhaps I misunderstood the discussion all
along though, let me know!  :-)

Thanks,
Ludo’.