Now that we're using a dedicated type for index entries everywhere,
we can access fields in them by name instead of integer offset.
This change has a significant impact on performance on the Firefox
repository. (Values are from before refactor, parent commit, this
commit.)
$ HGMODULEPOLICY=c hg perfrevset '::tip'
! wall 0.755869 comb 0.750000 user 0.750000 sys 0.000000 (best of 13)
! wall 1.011107 comb 1.010000 user 1.010000 sys 0.000000 (best of 10)
! wall 0.864906 comb 0.860000 user 0.860000 sys 0.000000 (best of 11)
$ HGMODULEPOLICY=py hg perfrevset '::tip'
! wall 1.366281 comb 1.360000 user 1.360000 sys 0.000000 (best of 7)
! wall 1.860068 comb 1.860000 user 1.860000 sys 0.000000 (best of 5)
! wall 1.672432 comb 1.680000 user 1.670000 sys 0.010000 (best of 6)
And with PyPy:
! wall 0.163141 comb 0.160000 user 0.160000 sys 0.000000 (best of 56)
! wall 0.154325 comb 0.160000 user 0.160000 sys 0.000000 (best of 54)
! wall 0.155534 comb 0.160000 user 0.160000 sys 0.000000 (best of 53)
The C extension is ~15% slower than before the refactor. This is a
bit unfortunate. That is a bit steep price to pay for more readable
code and the establishment of a formal interface for index entries.
However, all is not lost! Because we're now using a custom type and
conforming to a yet-to-be-formally-defined interface, there's nothing
preventing us from implementing a backed-by-C custom type for revlog
entries. This type could lazily resolve PyObject instances, which
should result in a massive performance boost for operations that
don't need to access all fields of the index entry. This is easier
done *after* we drop all uses of tuples and their API for referring
to index entries.