• Georges Racinet's avatar
    Markdown renderings: lookup for Mercurial short nodes · 31146d7c450d
    Georges Racinet authored
    The `CommitReferenceFilter` class is the one responsible for
    the rendering.
    We're *adding* resolution of truncated Mercurial Node ids for
    the case of the `hg_git` VCS type, relying on the existing
    map of full Mercurial SHA (Node id) to Git SHA.
    This is very inefficient, and proper calls with low startup
    overhead to a persistent Mercurial nodemap would do much better
    above a certain repository size (persistent nodemap is provided
    by Rust native extensions, and low overhead would be achieved only
    by a fastpath without Python or a long-running process, such as
    While the `Git::Commit.batch_by_oid` method
    doesn't seem to be called except from the `#commits_by` method of the
    `Repository` model, the latter is used in several places
    of the application, with risks of breakage and/or severe performance
    degradation. For `hg_git` VCS type, most callers don't need the Mercurial
    resolution. That's why we're executing the new lookup only if
    the new `hg_full_resolution` argument is set to `true`.
    Preliminary performance analysis (non scientific, on my workstation)
    shows that in the 100k changesets range (pypy repo) this naive lookup takes
    about 30ms, whereas `hg log -T` is in the 100-200ms ballpark.
    Around 500k changesets (mozilla-central repo), times have the same order
    of magnitude (around 100-200ms again). To insist, this is with the hg startup
    overhead and without the Rust persistent nodemap (would take less than 1ms).
    We fully expect the current hg<->git maps to be an unbereable performance
    problem in Heptapod anyway around 500k to 1M changesets anyway, only solved
    by HGitaly.
    All in all, the performance question seems to be acceptable in the current
    inefficient context *for Note rendering*.
    HGitaly would provide an efficient RPC call anyway.
    branch : heptapod-stable