lookup for Mercurial short nodes in Notes
This rough experiment provides #343 (closed), but needs more time for inclusion. Like the parent changeset, it does not provide migration for previously rendered Notes
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 has too much impact to make it into Heptapod 0.16.0, which
is around the corner: while the Git::Commit.batch_by_oid
method
doesn't seem to be called except from the #commits_by
method of the
Repository
mode, the latter is used in several places
of the application, with risks of breakage and/or severe performance
degradation.
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 HGitaly)
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.
Closes #202 (closed)