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

r36160:5e947367 default
r38755:be498426 default
Show More
Makefile.python
76 lines | 3.1 KiB | text/x-makefile | MakefileLexer
PYTHONVER=2.7.14
PYTHONNAME=python-
PREFIX=$(HOME)/bin/prefix-$(PYTHONNAME)$(PYTHONVER)
SYMLINKDIR=$(HOME)/bin
help:
@echo
@echo 'Make a custom installation of a Python version'
@echo
@echo 'Common make parameters:'
@echo ' PYTHONVER=... [$(PYTHONVER)]'
@echo ' PREFIX=... [$(PREFIX)]'
@echo ' SYMLINKDIR=... [$(SYMLINKDIR) creating $(PYTHONNAME)$(PYTHONVER)]'
@echo
@echo 'Common make targets:'
@echo ' python - install Python $$PYTHONVER in $$PREFIX'
@echo ' symlink - create a $$SYMLINKDIR/$(PYTHONNAME)$$PYTHONVER symlink'
@echo
@echo 'Example: create a temporary Python installation:'
@echo ' $$ make -f Makefile.python python PYTHONVER=${PYTHONVER} PREFIX=/tmp/p27'
@echo ' $$ /tmp/p27/bin/python -V'
@echo ' Python 2.7'
@echo
@echo 'Some external libraries are required for building Python: zlib bzip2 openssl.'
@echo 'Make sure their development packages are installed systemwide.'
# fedora: yum install zlib-devel bzip2-devel openssl-devel
# debian: apt-get install zlib1g-dev libbz2-dev libssl-dev
@echo
@echo 'To build a nice collection of interesting Python versions:'
@echo ' $$ for v in 2.{6{,.1,.2,.9},7{,.8,.10}}; do'
@echo ' make -f Makefile.python symlink PYTHONVER=$$v || break; done'
@echo 'To run a Mercurial test on all these Python versions:'
@echo ' $$ for py in `cd ~/bin && ls $(PYTHONNAME)2.*`; do'
@echo ' echo $$py; $$py run-tests.py test-http.t; echo; done'
@echo
export LANGUAGE=C
export LC_ALL=C
python: $(PREFIX)/bin/python docutils
printf 'import sys, zlib, bz2, docutils, ssl' | $(PREFIX)/bin/python
PYTHON_SRCDIR=Python-$(PYTHONVER)
PYTHON_SRCFILE=$(PYTHON_SRCDIR).tgz
$(PREFIX)/bin/python:
[ -f $(PYTHON_SRCFILE) ] || wget http://www.python.org/ftp/python/$(PYTHONVER)/$(PYTHON_SRCFILE) || curl -OL http://www.python.org/ftp/python/$(PYTHONVER)/$(PYTHON_SRCFILE) || [ -f $(PYTHON_SRCFILE) ]
rm -rf $(PYTHON_SRCDIR)
tar xf $(PYTHON_SRCFILE)
# Debian/Ubuntu disables SSLv2,3 the hard way, disable it on old Pythons too
-sed -i 's,self.*SSLv[23]_method(),0;//\0,g' $(PYTHON_SRCDIR)/Modules/_ssl.c
# Find multiarch system libraries on Ubuntu and disable fortify error when setting argv
LDFLAGS="-L/usr/lib/`dpkg-architecture -qDEB_HOST_MULTIARCH`"; \
BASECFLAGS=-U_FORTIFY_SOURCE; \
export LDFLAGS BASECFLAGS; \
cd $(PYTHON_SRCDIR) && ./configure --prefix=$(PREFIX) && make all SVNVERSION=pwd && make install
printf 'import sys, zlib, bz2, ssl' | $(PREFIX)/bin/python
rm -rf $(PYTHON_SRCDIR)
DOCUTILSVER=0.12
DOCUTILS_SRCDIR=docutils-$(DOCUTILSVER)
DOCUTILS_SRCFILE=$(DOCUTILS_SRCDIR).tar.gz
docutils: $(PREFIX)/bin/python
@$(PREFIX)/bin/python -c 'import docutils' || ( set -ex; \
[ -f $(DOCUTILS_SRCFILE) ] || wget http://downloads.sourceforge.net/project/docutils/docutils/$(DOCUTILSVER)/$(DOCUTILS_SRCFILE) || [ -f $(DOCUTILS_SRCFILE) ]; \
rm -rf $(DOCUTILS_SRCDIR); \
tar xf $(DOCUTILS_SRCFILE); \
cd $(DOCUTILS_SRCDIR) && $(PREFIX)/bin/python setup.py install --prefix=$(PREFIX); \
$(PREFIX)/bin/python -c 'import docutils'; \
rm -rf $(DOCUTILS_SRCDIR); )
symlink: python $(SYMLINKDIR)
ln -sf $(PREFIX)/bin/python $(SYMLINKDIR)/$(PYTHONNAME)$(PYTHONVER)
.PHONY: help python docutils symlink