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

r26781:1aee2ab0 default
r38755:be498426 default
Show More
hgweb.txt
86 lines | 3.3 KiB | text/plain | TextLexer
Matt Mackall
help: add some help for hgweb.config files
r10999 Mercurial's internal web server, hgweb, can serve either a single
Mads Kiilerich
help: improve hgweb help...
r17104 repository, or a tree of repositories. In the second case, repository
paths and global options can be defined using a dedicated
configuration file common to :hg:`serve`, ``hgweb.wsgi``,
``hgweb.cgi`` and ``hgweb.fcgi``.
Matt Mackall
help: add some help for hgweb.config files
r10999
Mads Kiilerich
help: improve hgweb help...
r17104 This file uses the same syntax as other Mercurial configuration files
but recognizes only the following sections:
Matt Mackall
help: add some help for hgweb.config files
r10999
- web
- paths
- collections
Mads Kiilerich
fix trivial spelling errors
r17424 The ``web`` options are thoroughly described in :hg:`help config`.
Mads Kiilerich
help: improve hgweb help...
r17104
The ``paths`` section maps URL paths to paths of repositories in the
filesystem. hgweb will not expose the filesystem directly - only
Mercurial repositories can be published and only according to the
configuration.
Matt Mackall
help: add some help for hgweb.config files
r10999
Mads Kiilerich
help: improve hgweb help...
r17104 The left hand side is the path in the URL. Note that hgweb reserves
subpaths like ``rev`` or ``file``, try using different names for
nested repositories to avoid confusing effects.
The right hand side is the path in the filesystem. If the specified
path ends with ``*`` or ``**`` the filesystem will be searched
recursively for repositories below that point.
With ``*`` it will not recurse into the repositories it finds (except for
``.hg/patches``).
With ``**`` it will also search inside repository working directories
and possibly find subrepositories.
In this example::
Matt Mackall
help: add some help for hgweb.config files
r10999
[paths]
Mads Kiilerich
help: improve hgweb help...
r17104 /projects/a = /srv/tmprepos/a
/projects/b = c:/repos/b
/ = /srv/repos/*
/user/bob = /home/bob/repos/**
Matt Mackall
help: add some help for hgweb.config files
r10999
- The first two entries make two repositories in different directories
appear under the same directory in the web interface
Mads Kiilerich
help: improve hgweb help...
r17104 - The third entry will publish every Mercurial repository found in
``/srv/repos/``, for instance the repository ``/srv/repos/quux/``
will appear as ``http://server/quux/``
- The fourth entry will publish both ``http://server/user/bob/quux/``
and ``http://server/user/bob/quux/testsubrepo/``
Matt Mackall
help: add some help for hgweb.config files
r10999
Javi Merino
help/hgweb: fix spelling error
r17333 The ``collections`` section is deprecated and has been superseded by
Mads Kiilerich
help: improve hgweb help...
r17104 ``paths``.
Gregory Szorc
help.hgweb: add a section describing URLs and common parameters...
r24079
URLs and Common Arguments
=========================
URLs under each repository have the form ``/{command}[/{arguments}]``
where ``{command}`` represents the name of a command or handler and
``{arguments}`` represents any number of additional URL parameters
to that command.
The web server has a default style associated with it. Styles map to
a collection of named templates. Each template is used to render a
specific piece of data, such as a changeset or diff.
The style for the current request can be overwritten two ways. First,
if ``{command}`` contains a hyphen (``-``), the text before the hyphen
defines the style. For example, ``/atom-log`` will render the ``log``
command handler with the ``atom`` style. The second way to set the
style is with the ``style`` query string argument. For example,
``/log?style=atom``. The hyphenated URL parameter is preferred.
Not all templates are available for all styles. Attempting to use
a style that doesn't have all templates defined may result in an error
rendering the page.
Many commands take a ``{revision}`` URL parameter. This defines the
changeset to operate on. This is commonly specified as the short,
Mads Kiilerich
spelling: trivial spell checking
r26781 12 digit hexadecimal abbreviation for the full 40 character unique
Gregory Szorc
help.hgweb: add a section describing URLs and common parameters...
r24079 revision identifier. However, any value described by
:hg:`help revisions` typically works.
Gregory Szorc
help: add web commands to help documentation...
r24080
Commands and URLs
=================
The following web commands and their URLs are available:
.. webcommandsmarker