view tests/test-mq-pull-from-bundle.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

#require repobundlerepo

  $ cat <<EOF >> $HGRCPATH
  > [extensions]
  > mq=
  > [alias]
  > tlog = log --template "{rev}: {node|short} {desc}\\n"
  > theads = heads --template "{rev}: {desc}\\n"
  > tincoming = incoming --template "{rev}: {desc}\\n"
  > EOF

Setup main:

  $ hg init base
  $ cd base
  $ echo "One" > one
  $ hg add
  adding one
  $ hg ci -m "main: one added"
  $ echo "++" >> one
  $ hg ci -m "main: one updated"

Bundle main:

  $ hg bundle --base=null ../main.hg
  2 changesets found

  $ cd ..

Incoming to fresh repo:

  $ hg init fresh

  $ hg -R fresh tincoming main.hg
  comparing with main.hg
  0: main: one added
  1: main: one updated
  $ test -f ./fresh/.hg/hg-bundle* && echo 'temp. bundle file remained' || true

  $ hg -R fresh tincoming bundle:fresh+main.hg
  comparing with bundle:fresh+main.hg
  0: main: one added
  1: main: one updated


Setup queue:

  $ cd base
  $ hg qinit -c
  $ hg qnew -m "patch: two added" two.patch
  $ echo two > two
  $ hg add
  adding two
  $ hg qrefresh
  $ hg qcommit -m "queue: two.patch added"
  $ hg qpop -a
  popping two.patch
  patch queue now empty

Bundle queue:

  $ hg -R .hg/patches bundle --base=null ../queue.hgq
  1 changesets found
  $ test -f ./fresh/.hg/hg-bundle* && echo 'temp. bundle file remained' || true

  $ cd ..


Clone base:

  $ hg clone base copy
  updating to branch default
  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
  $ cd copy
  $ hg qinit -c

Incoming queue bundle:

  $ hg -R .hg/patches tincoming ../queue.hgq
  comparing with ../queue.hgq
  0: queue: two.patch added
  $ test -f .hg/hg-bundle* && echo 'temp. bundle file remained' || true

Pull queue bundle:

  $ hg -R .hg/patches pull --update ../queue.hgq
  pulling from ../queue.hgq
  requesting all changes
  adding changesets
  adding manifests
  adding file changes
  added 1 changesets with 3 changes to 3 files
  new changesets d7553909353d
  merging series
  2 files updated, 1 files merged, 0 files removed, 0 files unresolved
  $ test -f .hg/patches/hg-bundle* && echo 'temp. bundle file remained' || true

  $ hg -R .hg/patches theads
  0: queue: two.patch added

  $ hg -R .hg/patches tlog
  0: d7553909353d queue: two.patch added

  $ hg qseries
  two.patch

  $ cd ..


Clone base again:

  $ hg clone base copy2
  updating to branch default
  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
  $ cd copy2
  $ hg qinit -c

Unbundle queue bundle:

  $ hg -R .hg/patches unbundle --update ../queue.hgq
  adding changesets
  adding manifests
  adding file changes
  added 1 changesets with 3 changes to 3 files
  new changesets d7553909353d
  merging series
  2 files updated, 1 files merged, 0 files removed, 0 files unresolved

  $ hg -R .hg/patches theads
  0: queue: two.patch added

  $ hg -R .hg/patches tlog
  0: d7553909353d queue: two.patch added

  $ hg qseries
  two.patch

  $ cd ..