##// END OF EJS Templates
merge: mark file gets as not thread safe (issue5933)...
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

File last commit:

r30406:cff0f592 default
r38755:be498426 default
Show More
revset.py
53 lines | 1.6 KiB | text/x-python | PythonLexer
# revset.py - asv revset benchmarks
#
# Copyright 2016 Logilab SA <contact@logilab.fr>
#
# This software may be used and distributed according to the terms of the
# GNU General Public License version 2 or any later version.
'''ASV revset benchmarks generated from contrib/base-revsets.txt
Each revset benchmark is parameterized with variants (first, last, sort, ...)
'''
from __future__ import absolute_import
import os
import string
import sys
from . import basedir, perfbench
def createrevsetbenchmark(baseset, variants=None):
if variants is None:
# Default variants
variants = ["plain", "first", "last", "sort", "sort+first",
"sort+last"]
fname = "track_" + "_".join("".join([
c if c in string.digits + string.letters else " "
for c in baseset
]).split())
def wrap(fname, baseset):
@perfbench(name=baseset, params=[("variant", variants)])
def f(perf, variant):
revset = baseset
if variant != "plain":
for var in variant.split("+"):
revset = "%s(%s)" % (var, revset)
return perf("perfrevset", revset)
f.__name__ = fname
return f
return wrap(fname, baseset)
def initializerevsetbenchmarks():
mod = sys.modules[__name__]
with open(os.path.join(basedir, 'contrib', 'base-revsets.txt'),
'rb') as fh:
for line in fh:
baseset = line.strip()
if baseset and not baseset.startswith('#'):
func = createrevsetbenchmark(baseset)
setattr(mod, func.__name__, func)
initializerevsetbenchmarks()