##// 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:

r32421:778dc37c default
r38755:be498426 default
Show More
check-py3-compat.py
96 lines | 3.1 KiB | text/x-python | PythonLexer
#!/usr/bin/env python
#
# check-py3-compat - check Python 3 compatibility of Mercurial files
#
# Copyright 2015 Gregory Szorc <gregory.szorc@gmail.com>
#
# This software may be used and distributed according to the terms of the
# GNU General Public License version 2 or any later version.
from __future__ import absolute_import, print_function
import ast
import importlib
import os
import sys
import traceback
def check_compat_py2(f):
"""Check Python 3 compatibility for a file with Python 2"""
with open(f, 'rb') as fh:
content = fh.read()
root = ast.parse(content)
# Ignore empty files.
if not root.body:
return
futures = set()
haveprint = False
for node in ast.walk(root):
if isinstance(node, ast.ImportFrom):
if node.module == '__future__':
futures |= set(n.name for n in node.names)
elif isinstance(node, ast.Print):
haveprint = True
if 'absolute_import' not in futures:
print('%s not using absolute_import' % f)
if haveprint and 'print_function' not in futures:
print('%s requires print_function' % f)
def check_compat_py3(f):
"""Check Python 3 compatibility of a file with Python 3."""
with open(f, 'rb') as fh:
content = fh.read()
try:
ast.parse(content)
except SyntaxError as e:
print('%s: invalid syntax: %s' % (f, e))
return
# Try to import the module.
# For now we only support modules in packages because figuring out module
# paths for things not in a package can be confusing.
if (f.startswith(('hgdemandimport/', 'hgext/', 'mercurial/'))
and not f.endswith('__init__.py')):
assert f.endswith('.py')
name = f.replace('/', '.')[:-3]
try:
importlib.import_module(name)
except Exception as e:
exc_type, exc_value, tb = sys.exc_info()
# We walk the stack and ignore frames from our custom importer,
# import mechanisms, and stdlib modules. This kinda/sorta
# emulates CPython behavior in import.c while also attempting
# to pin blame on a Mercurial file.
for frame in reversed(traceback.extract_tb(tb)):
if frame.name == '_call_with_frames_removed':
continue
if 'importlib' in frame.filename:
continue
if 'mercurial/__init__.py' in frame.filename:
continue
if frame.filename.startswith(sys.prefix):
continue
break
if frame.filename:
filename = os.path.basename(frame.filename)
print('%s: error importing: <%s> %s (error at %s:%d)' % (
f, type(e).__name__, e, filename, frame.lineno))
else:
print('%s: error importing module: <%s> %s (line %d)' % (
f, type(e).__name__, e, frame.lineno))
if __name__ == '__main__':
if sys.version_info[0] == 2:
fn = check_compat_py2
else:
fn = check_compat_py3
for f in sys.argv[1:]:
fn(f)
sys.exit(0)