##// END OF EJS Templates
discovery: slowly increase sampling size...
discovery: slowly increase sampling size Some pathological discovery runs can requires many roundtrip. When this happens things can get very slow. To make the algorithm more resilience again such pathological case. We slowly increase the sample size with each roundtrip (+5%). This will have a negligible impact on "normal" discovery with few roundtrips, but a large positive impact of case with many roundtrips. Asking more question per roundtrip helps to reduce the undecided set faster. Instead of reducing the undecided set a linear speed (in the worst case), we reduce it as a guaranteed (small) exponential rate. The data below show this slow ramp up in sample size: round trip | 1 | 5 | 10 | 20 | 50 | 100 | 130 | sample size | 200 | 254 | 321 | 517 | 2 199 | 25 123 | 108 549 | covered nodes | 200 | 1 357 | 2 821 | 7 031 | 42 658 | 524 530 | 2 276 755 | To be a bit more concrete, lets take a very pathological case as an example. We are doing discovery from a copy of Mozilla-try to a more recent version of mozilla-unified. Mozilla-unified heads are unknown to the mozilla-try repo and there are over 1 million "missing" changesets. (the discovery is "local" to avoid network interference) Without this change, the discovery: - last 1858 seconds (31 minutes), - does 1700 round trip, - asking about 340 000 nodes. With this change, the discovery: - last 218 seconds (3 minutes, 38 seconds a -88% improvement), - does 94 round trip (-94%), - asking about 344 211 nodes (+1%). Of course, this is an extreme case (and 3 minutes is still slow). However this give a good example of how this sample size increase act as a safety net catching any bad situations. We could image a steeper increase than 5%. For example 10% would give the following number: round trip | 1 | 5 | 10 | 20 | 50 | 75 | 100 | sample size | 200 | 321 | 514 | 1 326 | 23 060 | 249 812 | 2 706 594 | covered nodes | 200 | 1 541 | 3 690 | 12 671 | 251 871 | 2 746 254 | 29 770 966 | In parallel, it is useful to understand these pathological cases and improve them. However the current change provides a general purpose safety net to smooth the impact of pathological cases. To avoid issue with older http server, the increase in sample size only occurs if the protocol has not limit on command argument size.

File last commit:

r40602:5b530d76 stable
r42546:dbd0fcca default
Show More
config.txt
109 lines | 3.1 KiB | text/plain | TextLexer
Boris Feld
internal-doc: document the config register mechanism...
r34933 All config options used within Mercurial should be registered.
Config Option in Core
=====================
Config options used by Mercurial core are registered in the
``mercurial.configitems`` module.
Simple entry
------------
A registration entry typically looks like::
coreconfigitem('section', 'option',
default=MyDefaultValue,
)
Once registered, Mercurial will know that ``section.option`` is a legitimate
config option and that ``MyDefaultValue`` should be used if no other values are
defined in configuration files.
Complex default value
---------------------
If the default provided is a callable, it is called to retrieve the default
Matt Harbison
help: minor copy editing for grammar
r34950 value when accessing the config option. This is useful for default values that
Boris Feld
internal-doc: document the config register mechanism...
r34933 are mutable like the empty list::
coreconfigitem('pager', 'ignore',
default=list,
)
In addition, there are cases where the default is not fixed, but computed from
Matt Harbison
help: minor copy editing for grammar
r34950 other properties. In this case, use the ``dynamicdefault`` object as the value
for the ``default`` parameter. A default value is then explicitly required when
Boris Feld
internal-doc: document the config register mechanism...
r34933 reading the option::
# registration
coreconfigitem('web', 'name',
default=dynamicdefault,
)
# usage
Matt Harbison
help: minor copy editing for grammar
r34950 ui.config('web', 'name', dirname)
Boris Feld
internal-doc: document the config register mechanism...
r34933
Free form options
-----------------
Some config sections use free form options (e.g. ``paths``). You can register
them using the ``generic`` parameters::
coreconfigitem('paths', '.*',
default=None,
generic=True,
)
When ``generic=True`` is set, the option name is matched as a regular expression
(rooted to string start). It can be used to select specific sub parameters::
coreconfigitem('merge-tools', br'.*\.args$',
default="$local $base $other",
generic=True,
priority=-1,
)
Matt Harbison
help: minor copy editing for grammar
r34950 The ``priority`` parameter controls the order used to match the generic pattern
Boris Feld
internal-doc: document the config register mechanism...
r34933 (lower first).
Config Option in Extensions
===========================
General case
------------
Extensions should register config items through the ``registrar`` API (also used
for commands and others)::
configtable = {}
configitem = registrar.configitem(configtable)
configitem('blackbox', 'dirty',
default=False,
)
The ``dynamicdefault`` object is then available as
``configitem.dynamicdefault``.
Matt Harbison
help: minor copy editing for grammar
r34950 Supporting older versions
-------------------------
Boris Feld
internal-doc: document the config register mechanism...
r34933
Kevin Bullock
internals: copy-edit "register" -> "registrar" in configitem docs
r34952 The registrar was introduced in Mercurial 4.3, and the ``generic`` parameter was
Boris Feld
internal-doc: document the config register mechanism...
r34933 introduced in 4.4. Starting with Mercurial 4.4, all core options were registered
and developer warnings are emitted when accessing unregistered option.
Matt Harbison
help: minor copy editing for grammar
r34950 Extensions supporting versions older than Mercurial 4.3 cannot rely on the
default value being registered. The simplest way to register an option while
still supporting an older version is to use ``dynamicdefault`` for options
requiring a default value. The existing code passing an explicit default can
then stay in use until compatibility with Mercurial 4.2 is dropped.
Boris Feld
internal-doc: document the config register mechanism...
r34933
Matt Harbison
help: minor copy editing for grammar
r34950 As reminder, here are the default values for each config type:
Matt Harbison
help: unjumble the list of default config values for `internals.config`
r40602
- config: None
- configbool: False
- configbytes: 0
- configdate: None
- configint: None
- configlist: []
- configpath: None