GNU bug report logs - #65787
time-machine is doing too much network requests

Previous Next

Full log

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

From: Ludovic Courtès <ludo <at> gnu.org>
To: Simon Tournier <zimon.toutoune <at> gmail.com>
Cc: 65787 <at> debbugs.gnu.org
Subject: Re: bug#65787: time-machine is doing too much network requests
Date: Sun, 10 Sep 2023 22:10:36 +0200

Hello Simon,

This is a long message; I agree with the intent (avoiding network
traffic when the required commit is already in cache), but I’m not sure
about the analysis.  It would probably be easier if you could come with
an example where there’s Git-related network traffic where there
shouldn’t.

Let me give some perspective on what the code intends to do.

‘cached-channel-instance’ has 3 cases:

  1. Obvious cache hit: This is when CHANNELS specifies the commit of
     each target channel (this happens for example when you type ‘guix
     time-machine -q --commit=a4c35c607cfd7d6b0bad90cfcc46188d489e1754)
     *and* the combination of channels is already in
     ~/.cache/guix/inferiors.  This is the optimal case: the Git repo
     doesn’t even need to be opened.

  2. Cache hit: CHANNELS are pinned, but refer to tags (like “v1.2.0”)
     or short commit IDs (like “a4c35c6”).  In that case,
     ‘channel-full-commit’ opens the Git repo to resolve the identifier.
     After that, we go to case #1 or #4.

  3. Cache hit: CHANNELS are not pinned—i.e., they refer to a branch,
     not a commit.  In that case we first need to perform a ‘git fetch’
     and then we go to #1 or #4.

  4. Cache miss: ‘reference-available?’ returns #f for the channel
     commits, we got through ‘remote-fetch’ followed by
     ‘build-derivations’.

As with all caches, what matters is to make sure case #1 is processes as
efficiently as possible.  I believe it’s the case since the Git repo is
not even opened.

Of course it would be nice to speed up #2 and #3 too (as long as it’s
not at the expense of #1).  Maybe this is the purpose of your message:
reducing Git remote accesses in those cases?  (Apologies, I just
realized this might have been what you had in mind.  :-))

Thanks,
Ludo’.

Previous Next

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