Mercurial > hg
view tests/test-commit-unresolved.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 | 41ef02ba329b |
children | 3bc400ccbf99 |
line wrap: on
line source
$ addcommit () { > echo $1 > $1 > hg add $1 > hg commit -d "${2} 0" -m $1 > } $ commit () { > hg commit -d "${2} 0" -m $1 > } $ hg init a $ cd a $ addcommit "A" 0 $ addcommit "B" 1 $ echo "C" >> A $ commit "C" 2 $ hg update -C 0 1 files updated, 0 files merged, 1 files removed, 0 files unresolved $ echo "D" >> A $ commit "D" 3 created new head State before the merge $ hg status $ hg id e45016d2b3d3 tip $ hg summary parent: 3:e45016d2b3d3 tip D branch: default commit: (clean) update: 2 new changesets, 2 branch heads (merge) phases: 4 draft Testing the abort functionality first in case of conflicts $ hg merge --abort abort: no merge in progress [255] $ hg merge merging A warning: conflicts while merging A! (edit, then use 'hg resolve --mark') 1 files updated, 0 files merged, 0 files removed, 1 files unresolved use 'hg resolve' to retry unresolved file merges or 'hg merge --abort' to abandon [1] $ hg merge --abort e4501 abort: cannot specify a node with --abort [255] $ hg merge --abort --rev e4501 abort: cannot specify both --rev and --abort [255] $ hg merge --abort aborting the merge, updating back to e45016d2b3d3 1 files updated, 0 files merged, 1 files removed, 0 files unresolved Checking that we got back in the same state $ hg status ? A.orig $ hg id e45016d2b3d3 tip $ hg summary parent: 3:e45016d2b3d3 tip D branch: default commit: 1 unknown (clean) update: 2 new changesets, 2 branch heads (merge) phases: 4 draft Merging a conflict araises $ hg merge merging A warning: conflicts while merging A! (edit, then use 'hg resolve --mark') 1 files updated, 0 files merged, 0 files removed, 1 files unresolved use 'hg resolve' to retry unresolved file merges or 'hg merge --abort' to abandon [1] Correct the conflict without marking the file as resolved $ echo "ABCD" > A $ hg commit -m "Merged" abort: unresolved merge conflicts (see 'hg help resolve') [255] Mark the conflict as resolved and commit $ hg resolve -m A (no more unresolved files) $ hg commit -m "Merged" Test that if a file is removed but not marked resolved, the commit still fails (issue4972) $ hg up ".^" 1 files updated, 0 files merged, 1 files removed, 0 files unresolved $ hg merge 2 merging A warning: conflicts while merging A! (edit, then use 'hg resolve --mark') 1 files updated, 0 files merged, 0 files removed, 1 files unresolved use 'hg resolve' to retry unresolved file merges or 'hg merge --abort' to abandon [1] $ hg rm --force A $ hg commit -m merged abort: unresolved merge conflicts (see 'hg help resolve') [255] $ hg resolve -ma (no more unresolved files) $ hg commit -m merged created new head Testing the abort functionality in case of no conflicts $ hg update -C 0 1 files updated, 0 files merged, 1 files removed, 0 files unresolved $ addcommit "E" 4 created new head $ hg id 68352a18a7c4 tip $ hg merge -r 4 2 files updated, 0 files merged, 0 files removed, 0 files unresolved (branch merge, don't forget to commit) $ hg merge --preview --abort abort: cannot specify --preview with --abort [255] $ hg merge --abort aborting the merge, updating back to 68352a18a7c4 1 files updated, 0 files merged, 1 files removed, 0 files unresolved $ hg id 68352a18a7c4 tip $ cd ..