GNU bug report logs -
#65787
time-machine is doing too much network requests
Previous Next
Full log
View this message in rfc822 format
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’.
This bug report was last modified 1 year and 278 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.