util: lower water mark when removing nodes after cost limit reached
See the inline comment for the reasoning here. This is a pretty
common strategy for garbage collectors, other cache-like primtives.
The performance impact is substantial:
$ hg perflrucachedict --size 4 --gets 1000000 --sets 1000000 --mixed 1000000 --costlimit 100
! inserts w/ cost limit
! wall 1.659181 comb 1.650000 user 1.650000 sys 0.000000 (best of 7)
! wall 1.722122 comb 1.720000 user 1.720000 sys 0.000000 (best of 6)
! mixed w/ cost limit
! wall 1.139955 comb 1.140000 user 1.140000 sys 0.000000 (best of 9)
! wall 1.182513 comb 1.180000 user 1.180000 sys 0.000000 (best of 9)
$ hg perflrucachedict --size 1000 --gets 1000000 --sets 1000000 --mixed 1000000 --costlimit 10000
! inserts
! wall 0.679546 comb 0.680000 user 0.680000 sys 0.000000 (best of 15)
! sets
! wall 0.825147 comb 0.830000 user 0.830000 sys 0.000000 (best of 13)
! inserts w/ cost limit
! wall 25.105273 comb 25.080000 user 25.080000 sys 0.000000 (best of 3)
! wall 1.724397 comb 1.720000 user 1.720000 sys 0.000000 (best of 6)
! mixed
! wall 0.807096 comb 0.810000 user 0.810000 sys 0.000000 (best of 13)
! mixed w/ cost limit
! wall 12.104470 comb 12.070000 user 12.070000 sys 0.000000 (best of 3)
! wall 1.190563 comb 1.190000 user 1.190000 sys 0.000000 (best of 9)
$ hg perflrucachedict --size 1000 --gets 1000000 --sets 1000000 --mixed 1000000 --costlimit 10000 --mixedgetfreq 90
! inserts
! wall 0.711177 comb 0.710000 user 0.710000 sys 0.000000 (best of 14)
! sets
! wall 0.846992 comb 0.850000 user 0.850000 sys 0.000000 (best of 12)
! inserts w/ cost limit
! wall 25.963028 comb 25.960000 user 25.960000 sys 0.000000 (best of 3)
! wall 2.184311 comb 2.180000 user 2.180000 sys 0.000000 (best of 5)
! mixed
! wall 0.728256 comb 0.730000 user 0.730000 sys 0.000000 (best of 14)
! mixed w/ cost limit
! wall 3.174256 comb 3.170000 user 3.170000 sys 0.000000 (best of 4)
! wall 0.773186 comb 0.770000 user 0.770000 sys 0.000000 (best of 13)
$ hg perflrucachedict --size 100000 --gets 1000000 --sets 1000000 --mixed 1000000 --mixedgetfreq 90 --costlimit 5000000
! gets
! wall 1.191368 comb 1.190000 user 1.190000 sys 0.000000 (best of 9)
! wall 1.195304 comb 1.190000 user 1.190000 sys 0.000000 (best of 9)
! inserts
! wall 0.950995 comb 0.950000 user 0.950000 sys 0.000000 (best of 11)
! inserts w/ cost limit
! wall 1.589732 comb 1.590000 user 1.590000 sys 0.000000 (best of 7)
! sets
! wall 1.094941 comb 1.100000 user 1.090000 sys 0.010000 (best of 9)
! mixed
! wall 0.936420 comb 0.940000 user 0.930000 sys 0.010000 (best of 10)
! mixed w/ cost limit
! wall 0.882780 comb 0.870000 user 0.870000 sys 0.000000 (best of 11)
This puts us ~2x slower than caches without cost accounting. And for
read-heavy workloads (the prime use cases for caches), performance is
nearly identical.
In the worst case (pure write workloads with cost accounting enabled),
we're looking at ~1.5us per insert on large caches. That seems "fast
enough."
Differential Revision: https://phab.mercurial-scm.org/D4505
$ hg init repo
$ cd repo
$ echo foo > foo
$ hg ci -qAm 'add foo'
$ echo >> foo
$ hg ci -m 'change foo'
$ hg up -qC 0
$ echo bar > bar
$ hg ci -qAm 'add bar'
$ hg log
changeset: 2:effea6de0384
tag: tip
parent: 0:bbd179dfa0a7
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: add bar
changeset: 1:ed1b79f46b9a
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: change foo
changeset: 0:bbd179dfa0a7
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: add foo
$ cd ..
don't show "(+1 heads)" message when pulling closed head
$ hg clone -q repo repo2
$ hg clone -q repo2 repo3
$ cd repo2
$ hg up -q 0
$ echo hello >> foo
$ hg ci -mx1
created new head
$ hg ci -mx2 --close-branch
$ cd ../repo3
$ hg heads -q --closed
2:effea6de0384
1:ed1b79f46b9a
$ hg pull
pulling from $TESTTMP/repo2
searching for changes
adding changesets
adding manifests
adding file changes
added 2 changesets with 1 changes to 1 files
new changesets 8c900227dd5d:00cfe9073916
(run 'hg update' to get a working copy)
$ hg heads -q --closed
4:00cfe9073916
2:effea6de0384
1:ed1b79f46b9a
$ cd ..
$ hg init copy
$ cd copy
Pull a missing revision:
$ hg pull -qr missing ../repo
abort: unknown revision 'missing'!
[255]
Pull multiple revisions with update:
$ hg pull -qu -r 0 -r 1 ../repo
$ hg -q parents
0:bbd179dfa0a7
$ hg rollback
repository tip rolled back to revision -1 (undo pull)
working directory now based on revision -1
$ hg pull -qr 0 ../repo
$ hg log
changeset: 0:bbd179dfa0a7
tag: tip
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: add foo
$ hg pull -qr 1 ../repo
$ hg log
changeset: 1:ed1b79f46b9a
tag: tip
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: change foo
changeset: 0:bbd179dfa0a7
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: add foo
This used to abort: received changelog group is empty:
$ hg pull -qr 1 ../repo
Test race condition with -r and -U (issue4707)
We pull '-U -r <name>' and the name change right after/during the changegroup emission.
We use http because http is better is our racy-est option.
$ echo babar > ../repo/jungle
$ cat <<EOF > ../repo/.hg/hgrc
> [hooks]
> outgoing.makecommit = hg ci -Am 'racy commit'; echo committed in pull-race
> EOF
$ hg serve -R ../repo -p $HGPORT2 -d --pid-file=../repo.pid
$ cat ../repo.pid >> $DAEMON_PIDS
$ hg pull --rev default --update http://localhost:$HGPORT2/
pulling from http://localhost:$HGPORT2/
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files (+1 heads)
new changesets effea6de0384
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg log -G
@ changeset: 2:effea6de0384
| tag: tip
| parent: 0:bbd179dfa0a7
| user: test
| date: Thu Jan 01 00:00:00 1970 +0000
| summary: add bar
|
| o changeset: 1:ed1b79f46b9a
|/ user: test
| date: Thu Jan 01 00:00:00 1970 +0000
| summary: change foo
|
o changeset: 0:bbd179dfa0a7
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: add foo
$ cd ..
$ killdaemons.py