manifest: persist the manifestfulltext cache
Reconstructing the manifest from the revlog takes time, so much so that there
already is a LRU cache to avoid having to load a manifest multiple times.
This patch persists that LRU cache in the .hg/cache directory, so we can re-use
this cache across hg commands. Commit benchmark (run on Macos 10.13 on a
2017-model Macbook Pro with Core i7 2.9GHz and flash drive), testing without
and with patch run 5 times, baseline is r2a227782e754:
* committing to an existing file, against the mozilla-central repository.
Baseline real time average 1.9692, with patch 1.3786.
A new debugcommand "hg debugmanifestfulltextcache" lets you inspect the cache,
clear it, or add specific manifest nodeids to it. When calling
repo.updatecaches(), the manifest(s) for the working copy parents are added to
the cache.
The hg perfmanifest command has an additional --clear-disk switch to clear this
cache when testing manifest loading performance.
Using this command to test performance on the firefox repository for revision
f947d902ed91, whose manifest has a delta chain length of 60540, we see:
$ hg perfmanifest f947d902ed91 --clear-disk
! wall 0.972253 comb 0.970000 user 0.850000 sys 0.120000 (best of 10)
$ hg debugmanifestfulltextcache -a `hg log --debug -r f947d902ed91 | grep manifest | cut -d: -f3`
Cache contains 1 manifest entries, in order of most to least recent:
id: 0294517df4aad07c70701db43bc7ff24c3ce7dbc, size 25.6 MB
Total cache data size 25.6 MB, on-disk 0 bytes
$ hg perfmanifest f947d902ed91
! wall 0.036748 comb 0.040000 user 0.020000 sys 0.020000 (best of 100)
Worst-case scenario: a manifest text loaded from a single delta; in the firefox
repository manifest node 9a1246ff762e is the chain base for the manifest
attached to revision f947d902ed91. Loading this from a full cache file is just
as fast as without the cache; the extra node ids ensure a big full cache:
$ for node in 9a1246ff762e 1a1922c14a3e 54a31d11a36a 0294517df4aa; do
> hgd debugmanifestfulltextcache -a $node > /dev/null
> done
$ hgd perfmanifest -m 9a1246ff762e
! wall 0.077513 comb 0.080000 user 0.030000 sys 0.050000 (best of 100)
$ hgd perfmanifest -m 9a1246ff762e --clear-disk
! wall 0.078547 comb 0.080000 user 0.070000 sys 0.010000 (best of 100)
this structure seems to tickle a bug in bundle's search for
changesets, so first we have to recreate it
o 8
|
| o 7
| |
| o 6
|/|
o | 5
| |
o | 4
| |
| o 3
| |
| o 2
|/
o 1
|
o 0
$ mkrev()
> {
> revno=$1
> echo "rev $revno"
> echo "rev $revno" > foo.txt
> hg -q ci -m"rev $revno"
> }
setup test repo1
$ hg init repo1
$ cd repo1
$ echo "rev 0" > foo.txt
$ hg ci -Am"rev 0"
adding foo.txt
$ mkrev 1
rev 1
first branch
$ mkrev 2
rev 2
$ mkrev 3
rev 3
back to rev 1 to create second branch
$ hg up -r1
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ mkrev 4
rev 4
$ mkrev 5
rev 5
merge first branch to second branch
$ hg up -C -r5
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ HGMERGE=internal:local hg merge
0 files updated, 1 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
$ echo "merge rev 5, rev 3" > foo.txt
$ hg ci -m"merge first branch to second branch"
one more commit following the merge
$ mkrev 7
rev 7
back to "second branch" to make another head
$ hg up -r5
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ mkrev 8
rev 8
the story so far
$ hg log -G --template "{rev}\n"
@ 8
|
| o 7
| |
| o 6
|/|
o | 5
| |
o | 4
| |
| o 3
| |
| o 2
|/
o 1
|
o 0
check that "hg outgoing" really does the right thing
sanity check of outgoing: expect revs 4 5 6 7 8
$ hg clone -r3 . ../repo2
adding changesets
adding manifests
adding file changes
added 4 changesets with 4 changes to 1 files
new changesets 6ae4cca4e39a:478f191e53f8
updating to branch default
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
this should (and does) report 5 outgoing revisions: 4 5 6 7 8
$ hg outgoing --template "{rev}\n" ../repo2
comparing with ../repo2
searching for changes
4
5
6
7
8
test bundle (destination repo): expect 5 revisions
this should bundle the same 5 revisions that outgoing reported, but it
actually bundles 7
$ hg bundle foo.bundle ../repo2
searching for changes
5 changesets found
test bundle (base revision): expect 5 revisions
this should (and does) give exactly the same result as bundle
with a destination repo... i.e. it's wrong too
$ hg bundle --base 3 foo.bundle
5 changesets found
$ cd ..