GNU bug report logs - #39258
Faster guix search using an sqlite cache

Previous Next

Package: guix-patches;

Reported by: Arun Isaac <arunisaac <at> systemreboot.net>

Date: Thu, 23 Jan 2020 19:53:02 UTC

Severity: important

Done: Arun Isaac <arunisaac <at> systemreboot.net>

Bug is archived. No further changes may be made.

Full log


Message #256 received at 39258 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Pierre Neidhardt <mail <at> ambrevar.xyz>
Cc: Arun Isaac <arunisaac <at> systemreboot.net>, 39258 <at> debbugs.gnu.org,
 zimoun <zimon.toutoune <at> gmail.com>
Subject: Re: [bug#39258] [PATCH v3 1/3] guix: Generate package metadata cache.
Date: Sun, 26 Apr 2020 17:33:37 +0200
Hey!

Pierre Neidhardt <mail <at> ambrevar.xyz> skribis:

> Ludovic Courtès <ludo <at> gnu.org> writes:
>
>> It’s complicated.  As it stands, I’d rather not add overhead to ‘guix
>> pull’, especially since current ‘guix search’ on my SSD is fast enough
>> and can hardly be made any faster.
>
> The question is, what is fast enough?  I have an NVMe here that has a
> throughput of some 2GB/s, and yet
>
> time guix search emacs > /dev/null
> real    0m1.545s
> user    0m1.938s
> sys     0m0.080s

That accounts for the time to render 864 entries:

  $ guix search emacs| grep ^name| wc -l
  864

Compare with:

  $ time guix search emacs | head -100 > /dev/null

  real    0m0.674s
  user    0m0.802s
  sys     0m0.048s

Again, this is not to say it cannot be improved, but it’s quite a
challenge to do better on such hardware.

Though as discussed with Arun, there may be low-hanging optimization
fruits in Texinfo parsing and rendering.  I guess we need to go ahead
fire up statprof now.  :-)

Ludo’.




This bug report was last modified 37 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.