view tests/test-convert-bzr-merges.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 bzr

N.B. bzr 1.13 has a bug that breaks this test.  If you see this
test fail, check your bzr version.  Upgrading to bzr 1.13.1
should fix it.

  $ . "$TESTDIR/bzr-definitions"

test multiple merges at once

  $ mkdir test-multimerge
  $ cd test-multimerge
  $ bzr init -q source
  $ cd source
  $ echo content > file
  $ bzr add -q file
  $ bzr commit -q -m 'Initial add' '--commit-time=2009-10-10 08:00:00 +0100'
  $ cd ..
  $ bzr branch -q source source-branch1
  $ cd source-branch1
  $ echo morecontent >> file
  $ echo evenmorecontent > file-branch1
  $ bzr add -q file-branch1
  $ bzr commit -q -m 'Added branch1 file' '--commit-time=2009-10-10 08:00:01 +0100'
  $ cd ../source
  $ sleep 1
  $ echo content > file-parent
  $ bzr add -q file-parent
  $ bzr commit -q -m 'Added parent file' '--commit-time=2009-10-10 08:00:02 +0100'
  $ cd ..
  $ bzr branch -q source source-branch2
  $ cd source-branch2
  $ echo somecontent > file-branch2
  $ bzr add -q file-branch2
  $ bzr commit -q -m 'Added brach2 file' '--commit-time=2009-10-10 08:00:03 +0100'
  $ sleep 1
  $ cd ../source
  $ bzr merge -q ../source-branch1
  $ bzr merge -q --force ../source-branch2
  $ bzr commit -q -m 'Merged branches' '--commit-time=2009-10-10 08:00:04 +0100'
  $ cd ..
  $ hg convert --datesort --config convert.bzr.saverev=False source source-hg
  initializing destination source-hg repository
  scanning source...
  sorting...
  converting...
  4 Initial add
  3 Added branch1 file
  2 Added parent file
  1 Added brach2 file
  0 Merged branches
  $ glog -R source-hg
  o    5@source "(octopus merge fixup)" files:
  |\
  | o    4@source "Merged branches" files: file-branch2
  | |\
  o---+  3@source-branch2 "Added brach2 file" files: file-branch2
   / /
  | o  2@source "Added parent file" files: file-parent
  | |
  o |  1@source-branch1 "Added branch1 file" files: file file-branch1
  |/
  o  0@source "Initial add" files: file
  
  $ manifest source-hg tip
  % manifest of tip
  644   file
  644   file-branch1
  644   file-branch2
  644   file-parent

  $ hg convert source-hg hg2hg
  initializing destination hg2hg repository
  scanning source...
  sorting...
  converting...
  5 Initial add
  4 Added branch1 file
  3 Added parent file
  2 Added brach2 file
  1 Merged branches
  0 (octopus merge fixup)
  $ hg -R hg2hg out source-hg -T compact
  comparing with source-hg
  searching for changes
  5[tip]:4,3   6bd55e826939   2009-10-10 08:00 +0100   foo
    (octopus merge fixup)
  
XXX: The manifest lines should probably agree, to avoid changing the hash when
converting hg -> hg

  $ hg -R source-hg log --debug -r tip
  changeset:   5:b209510f11b2c987f920749cd8e352aa4b3230f2
  branch:      source
  tag:         tip
  phase:       draft
  parent:      4:1dc38c377bb35eeea4fa955056fbe4440d54a743
  parent:      3:4aaba1bfb426b8941bbf63f9dd52301152695164
  manifest:    5:1109e42bdcbd1f51baa69bc91079011d77057dbb
  user:        Foo Bar <[e-mail]>
  date:        Sat Oct 10 08:00:04 2009 +0100
  extra:       branch=source
  description:
  (octopus merge fixup)
  
  
  $ hg -R hg2hg log --debug -r tip
  changeset:   5:6bd55e8269392769783345686faf7ff7b3b0215d
  branch:      source
  tag:         tip
  phase:       draft
  parent:      4:1dc38c377bb35eeea4fa955056fbe4440d54a743
  parent:      3:4aaba1bfb426b8941bbf63f9dd52301152695164
  manifest:    4:daa315d56a98ba20811fdd0d9d575861f65cfa8c
  user:        Foo Bar <[e-mail]>
  date:        Sat Oct 10 08:00:04 2009 +0100
  extra:       branch=source
  description:
  (octopus merge fixup)
  
  
  $ hg -R source-hg manifest --debug -r tip
  cdf31ed9242b209cd94697112160e2c5b37a667d 644   file
  5108144f585149b29779d7c7e51d61dd22303ffe 644   file-branch1
  80753c4a9ac3806858405b96b24a907b309e3616 644   file-branch2
  7108421418404a937c684d2479a34a24d2ce4757 644   file-parent
  $ hg -R source-hg manifest --debug -r 'tip^'
  cdf31ed9242b209cd94697112160e2c5b37a667d 644   file
  5108144f585149b29779d7c7e51d61dd22303ffe 644   file-branch1
  80753c4a9ac3806858405b96b24a907b309e3616 644   file-branch2
  7108421418404a937c684d2479a34a24d2ce4757 644   file-parent

  $ hg -R hg2hg manifest --debug -r tip
  cdf31ed9242b209cd94697112160e2c5b37a667d 644   file
  5108144f585149b29779d7c7e51d61dd22303ffe 644   file-branch1
  80753c4a9ac3806858405b96b24a907b309e3616 644   file-branch2
  7108421418404a937c684d2479a34a24d2ce4757 644   file-parent
  $ hg -R hg2hg manifest --debug -r 'tip^'
  cdf31ed9242b209cd94697112160e2c5b37a667d 644   file
  5108144f585149b29779d7c7e51d61dd22303ffe 644   file-branch1
  80753c4a9ac3806858405b96b24a907b309e3616 644   file-branch2
  7108421418404a937c684d2479a34a24d2ce4757 644   file-parent

  $ cd ..