From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:470:142:3::10]:34372) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jSis3-00028C-5Y for guix-patches@gnu.org; Sun, 26 Apr 2020 11:07:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jSis2-0001Nf-MZ for guix-patches@gnu.org; Sun, 26 Apr 2020 11:07:02 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:50596) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jSis2-0001Kc-A6 for guix-patches@gnu.org; Sun, 26 Apr 2020 11:07:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jSis2-0001xq-49 for guix-patches@gnu.org; Sun, 26 Apr 2020 11:07:02 -0400 Subject: [bug#39258] [PATCH v3 1/3] guix: Generate package metadata cache. Resent-Message-ID: MIME-Version: 1.0 References: <20200327162654.18785-1-arunisaac@systemreboot.net> <20200327162654.18785-2-arunisaac@systemreboot.net> <87h7x8haor.fsf@gnu.org> <87r1wa48n0.fsf@gnu.org> In-Reply-To: <87r1wa48n0.fsf@gnu.org> From: zimoun Date: Sun, 26 Apr 2020 17:05:48 +0200 Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: Arun Isaac , Pierre Neidhardt , 39258@debbugs.gnu.org Hi Ludo, On Sun, 26 Apr 2020 at 16:35, Ludovic Court=C3=A8s wrote: > Realistically though, I understand that things are different on slower > machines and/or spinning disks. That=E2=80=99s why I=E2=80=99m intereste= d in seeing how > Arun=E2=80=99s proposed changes can affect such machines. I understand. I have done a small benchmark [1] of the 3 ways: the current, the v2 using Xapian (which is not an option on the long term) and the v3. My "slower" machine is at my office... but it provides already interesting numbers, IMHO. [1] http://issues.guix.gnu.org/39258#78 > If, as a bonus, it allows us to have an inverted index and thus improve > the quality of search results, that=E2=80=99s great! This "issue" is: any improvement on both sides performance and accuracy would add an somehow extra cost. The question is what is the maximum users would accept to pay for? Well, it is complicated as you said. :-) A trade off between extra cost, maintenance, complexity, etc is not easy to draw, as you said too elsewhere. I am seeing all that as experimental: explore ideas to see if they are worth or not. And what should be concluded now could change in the (near) future; for example if the computations of derivations are faster, resulting on "guix pull" faster, etc.. Cheer, simon