view mercurial/help/hg.1.txt @ 33171:6d678ab1b10d

revlog: C implementation of delta chain resolution

I've seen revlog._deltachain() appear in a number of performance
profiles. I suspect there are 2 reasons for this:

1. Delta chain resolution performs many index lookups, thus triggering
   population of index tuples. Creating possibly tens of thousands of
   PyObject will have overhead.
2. Delta chain resolution is a tight loop.

By moving delta chain resolution to C, we can defer instantiation
of full index entry tuples and make the loop faster courtesy of
not running in Python.

We can measure the impact to delta chain resolution via
`hg perflogrevision` using the mozilla-central repo with a recent
manifest having delta chain length of 33726:

$ hg perfrevlogrevision -m 364895
! full
! wall 0.367585 comb 0.370000 user 0.340000 sys 0.030000 (best of 27)
! wall 0.357581 comb 0.360000 user 0.350000 sys 0.010000 (best of 28)
! deltachain
! wall 0.010644 comb 0.010000 user 0.010000 sys 0.000000 (best of 270)
! wall 0.000292 comb 0.000000 user 0.000000 sys 0.000000 (best of 8729)

$ hg perfrevlogrevision --cache -m 364895
! deltachain
! wall 0.003904 comb 0.000000 user 0.000000 sys 0.000000 (best of 712)
! wall 0.000284 comb 0.000000 user 0.000000 sys 0.000000 (best of 9926)

The first test measures savings from both not instantiating index
entries and moving to C. The second test (which doesn't clear the
index caches) essentially isolates the benefits of moving from Python
to C. It still shows a 13.7x speedup (versus 36.4x). And there are
multiple milliseconds of savings within the critical path for resolving
revision data. I think that justifies the existence of C code.

A more striking example of the benefits of this change can be
demonstrated by timing `hg debugdeltachain -m` for the mozilla-central
repo:

$ time hg debugdeltachain -m > /dev/null
before:        1057.4s
after:          503.3s
PyPy2.7 5.8.0:  220.0s

It's worth noting that the C code isn't as optimal as it could be.
We're still instantiating a new PyObject for every revision. A future
optimization would be to reuse the PyObject on the cached index tuple.
We could potentially also get wins by using a memory array of raw
integers. There is also room for a delta chain cache on revlog
instances. Of course, the best optimization is to implement revlog
reading outside of Python so Python doesn't need to be concerned
about the relatively expensive index entries and operations on them.

====
 hg
====

---------------------------------------
Mercurial source code management system
---------------------------------------

:Author:         Matt Mackall <[e-mail]>
:Organization:   Mercurial
:Manual section: 1
:Manual group:   Mercurial Manual

.. contents::
   :backlinks: top
   :class: htmlonly
   :depth: 1


Synopsis
""""""""
**hg** *command* [*option*]... [*argument*]...

Description
"""""""""""
The **hg** command provides a command line interface to the Mercurial
system.

Command Elements
""""""""""""""""

files...
    indicates one or more filename or relative path filenames; see
    `File Name Patterns`_ for information on pattern matching

path
    indicates a path on the local machine

revision
    indicates a changeset which can be specified as a changeset
    revision number, a tag, or a unique substring of the changeset
    hash value

repository path
    either the pathname of a local repository or the URI of a remote
    repository.

.. include:: hg.1.gendoc.txt

Files
"""""

``/etc/mercurial/hgrc``, ``$HOME/.hgrc``, ``.hg/hgrc``
    This file contains defaults and configuration. Values in
    ``.hg/hgrc`` override those in ``$HOME/.hgrc``, and these override
    settings made in the global ``/etc/mercurial/hgrc`` configuration.
    See |hgrc(5)|_ for details of the contents and format of these
    files.

``.hgignore``
    This file contains regular expressions (one per line) that
    describe file names that should be ignored by **hg**. For details,
    see |hgignore(5)|_.

``.hgsub``
    This file defines the locations of all subrepositories, and
    tells where the subrepository checkouts came from. For details, see
    :hg:`help subrepos`.

``.hgsubstate``
    This file is where Mercurial stores all nested repository states. *NB: This
    file should not be edited manually.*

``.hgtags``
    This file contains changeset hash values and text tag names (one
    of each separated by spaces) that correspond to tagged versions of
    the repository contents. The file content is encoded using UTF-8.

``.hg/last-message.txt``
    This file is used by :hg:`commit` to store a backup of the commit message
    in case the commit fails.

``.hg/localtags``
    This file can be used to define local tags which are not shared among
    repositories. The file format is the same as for ``.hgtags``, but it is
    encoded using the local system encoding.

Some commands (e.g. revert) produce backup files ending in ``.orig``,
if the ``.orig`` file already exists and is not tracked by Mercurial,
it will be overwritten.

Bugs
""""
Probably lots, please post them to the mailing list (see Resources_
below) when you find them.

See Also
""""""""
|hgignore(5)|_, |hgrc(5)|_

Author
""""""
Written by Matt Mackall <[e-mail]>

Resources
"""""""""
Main Web Site: https://mercurial-scm.org/

Source code repository: https://www.mercurial-scm.org/repo/hg

Mailing list: https://www.mercurial-scm.org/mailman/listinfo/mercurial/

Copying
"""""""
Copyright (C) 2005-2017 Matt Mackall.
Free use of this software is granted under the terms of the GNU General
Public License version 2 or any later version.

.. include:: common.txt