Mercurial > hg
view tests/test-rebase-check-restore.t @ 38732:be4984261611
merge: mark file gets as not thread safe (issue5933)
In default installs, this has the effect of disabling the thread-based
worker on Windows when manifesting files in the working directory. My
measurements have shown that with revlog-based repositories, Mercurial
spends a lot of CPU time in revlog code resolving file data. This ends
up incurring a lot of context switching across threads and slows down
`hg update` operations when going from an empty working directory to
the tip of the repo.
On mozilla-unified (246,351 files) on an i7-6700K (4+4 CPUs):
before: 487s wall
after: 360s wall (equivalent to worker.enabled=false)
cpus=2: 379s wall
Even with only 2 threads, the thread pool is still slower.
The introduction of the thread-based worker (02b36e860e0b) states that
it resulted in a "~50%" speedup for `hg sparse --enable-profile` and
`hg sparse --disable-profile`. This disagrees with my measurement
above. I theorize a few reasons for this:
1) Removal of files from the working directory is I/O - not CPU - bound
and should benefit from a thread pool (unless I/O is insanely fast
and the GIL release is near instantaneous). So tests like `hg sparse
--enable-profile` may exercise deletion throughput and aren't good
benchmarks for worker tasks that are CPU heavy.
2) The patch was authored by someone at Facebook. The results were
likely measured against a repository using remotefilelog. And I
believe that revision retrieval during working directory updates with
remotefilelog will often use a remote store, thus being I/O and not
CPU bound. This probably resulted in an overstated performance gain.
Since there appears to be a need to enable the thread-based worker with
some stores, I've made the flagging of file gets as thread safe
configurable. I've made it experimental because I don't want to formalize
a boolean flag for this option and because this attribute is best
captured against the store implementation. But we don't have a proper
store API for this yet. I'd rather cross this bridge later.
It is possible there are revlog-based repositories that do benefit from
a thread-based worker. I didn't do very comprehensive testing. If there
are, we may want to devise a more proper algorithm for whether to use
the thread-based worker, including possibly config options to limit the
number of threads to use. But until I see evidence that justifies
complexity, simplicity wins.
Differential Revision: https://phab.mercurial-scm.org/D3963
author | Gregory Szorc <gregory.szorc@gmail.com> |
---|---|
date | Wed, 18 Jul 2018 09:49:34 -0700 |
parents | 4441705b7111 |
children | dc5e5577af39 |
line wrap: on
line source
$ cat >> $HGRCPATH <<EOF > [extensions] > rebase= > > [phases] > publish=False > > [alias] > tglog = log -G --template "{rev}:{phase} '{desc}' {branches}\n" > EOF $ hg init a $ cd a $ echo A > A $ hg add A $ hg ci -m A $ echo 'B' > B $ hg add B $ hg ci -m B $ echo C >> A $ hg ci -m C $ hg up -q -C 0 $ echo D >> A $ hg ci -m D created new head $ echo E > E $ hg add E $ hg ci -m E $ hg up -q -C 0 $ hg branch 'notdefault' marked working directory as branch notdefault (branches are permanent and global, did you want a bookmark?) $ echo F >> A $ hg ci -m F $ cd .. Rebasing B onto E - check keep: and phases $ hg clone -q -u . a a1 $ cd a1 $ hg phase --force --secret 2 $ hg tglog @ 5:draft 'F' notdefault | | o 4:draft 'E' | | | o 3:draft 'D' |/ | o 2:secret 'C' | | | o 1:draft 'B' |/ o 0:draft 'A' $ hg rebase -s 1 -d 4 --keep rebasing 1:27547f69f254 "B" rebasing 2:965c486023db "C" merging A warning: conflicts while merging A! (edit, then use 'hg resolve --mark') unresolved conflicts (see hg resolve, then hg rebase --continue) [1] Solve the conflict and go on: $ echo 'conflict solved' > A $ rm A.orig $ hg resolve -m A (no more unresolved files) continue: hg rebase --continue $ hg rebase --continue already rebased 1:27547f69f254 "B" as 45396c49d53b rebasing 2:965c486023db "C" $ hg tglog o 7:secret 'C' | o 6:draft 'B' | | @ 5:draft 'F' notdefault | | o | 4:draft 'E' | | o | 3:draft 'D' |/ | o 2:secret 'C' | | | o 1:draft 'B' |/ o 0:draft 'A' $ cd .. Rebase F onto E - check keepbranches: $ hg clone -q -u . a a2 $ cd a2 $ hg phase --force --secret 2 $ hg tglog @ 5:draft 'F' notdefault | | o 4:draft 'E' | | | o 3:draft 'D' |/ | o 2:secret 'C' | | | o 1:draft 'B' |/ o 0:draft 'A' $ hg rebase -s 5 -d 4 --keepbranches rebasing 5:01e6ebbd8272 "F" (tip) merging A warning: conflicts while merging A! (edit, then use 'hg resolve --mark') unresolved conflicts (see hg resolve, then hg rebase --continue) [1] Solve the conflict and go on: $ echo 'conflict solved' > A $ rm A.orig $ hg resolve -m A (no more unresolved files) continue: hg rebase --continue $ hg rebase --continue rebasing 5:01e6ebbd8272 "F" (tip) saved backup bundle to $TESTTMP/a2/.hg/strip-backup/01e6ebbd8272-6fd3a015-rebase.hg $ hg tglog @ 5:draft 'F' notdefault | o 4:draft 'E' | o 3:draft 'D' | | o 2:secret 'C' | | | o 1:draft 'B' |/ o 0:draft 'A' $ cd ..