zimoun skribis: > On Tue, 11 Feb 2020 at 17:29, Ludovic Courtès 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 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’.