Mercurial > hg
view tests/test-known.t @ 37438:7b7ca9ba2de5
commands: don't violate storage abstractions in `manifest --all`
Previously, we asked the store to emit its data files. For modern
repos, this would use fncache to resolve the set of files then would
stat() each file. For my copy of the mozilla-unified repository, this
took 3.3-10s depending on the state of my filesystem cache to render
449,790 items.
The previous behavior was a massive layering violation because it
assumed tracked files would have specific filenames in specific
directories. Alternate storage backends would violate this assumption.
The new behavior scans the changelog entries for the set of files
changed by each commit. It aggregates them into a set and then
sorts and prints the result. This reliably takes ~16.3s on my
machine. ~80% of the time is spent in zlib decompression.
The performance regression is unfortunate. If we want to claw it
back, we can create a proper storage API to query for the set of
tracked files. I'm not opposed to doing that. But I'm in no hurry
because I suspect ~0 people care about the performance of
`hg manifest --all`.
.. perf::
`hg manifest --all` is likely slower due to changing its
implementation to respect storage interface boundaries. If you
are impacted by this regression in a meaningful way, please make
noise on the development mailing list and it can be dealt with.
Differential Revision: https://phab.mercurial-scm.org/D3119
author | Gregory Szorc <gregory.szorc@gmail.com> |
---|---|
date | Wed, 04 Apr 2018 21:27:02 -0700 |
parents | 8c14f87bd0ae |
children | b4b7427b5786 |
line wrap: on
line source
#require killdaemons = Test the known() protocol function = Create a test repository: $ hg init repo $ cd repo $ touch a ; hg add a ; hg ci -ma $ touch b ; hg add b ; hg ci -mb $ touch c ; hg add c ; hg ci -mc $ hg log --template '{node}\n' 991a3460af53952d10ec8a295d3d2cc2e5fa9690 0e067c57feba1a5694ca4844f05588bb1bf82342 3903775176ed42b1458a6281db4a0ccf4d9f287a $ cd .. Test locally: $ hg debugknown repo 991a3460af53952d10ec8a295d3d2cc2e5fa9690 0e067c57feba1a5694ca4844f05588bb1bf82342 3903775176ed42b1458a6281db4a0ccf4d9f287a 111 $ hg debugknown repo 000a3460af53952d10ec8a295d3d2cc2e5fa9690 0e067c57feba1a5694ca4844f05588bb1bf82342 0003775176ed42b1458a6281db4a0ccf4d9f287a 010 $ hg debugknown repo Test via HTTP: $ hg serve -R repo -p $HGPORT -d --pid-file=hg.pid -E error.log -A access.log $ cat hg.pid >> $DAEMON_PIDS $ hg debugknown http://localhost:$HGPORT/ 991a3460af53952d10ec8a295d3d2cc2e5fa9690 0e067c57feba1a5694ca4844f05588bb1bf82342 3903775176ed42b1458a6281db4a0ccf4d9f287a 111 $ hg debugknown http://localhost:$HGPORT/ 000a3460af53952d10ec8a295d3d2cc2e5fa9690 0e067c57feba1a5694ca4844f05588bb1bf82342 0003775176ed42b1458a6281db4a0ccf4d9f287a 010 $ hg debugknown http://localhost:$HGPORT/ $ cat error.log $ killdaemons.py