MQ performance on large repo
Adrian Buehlmann
adrian at cadifra.com
Wed Mar 3 10:52:08 CST 2010
On 02.03.2010 21:27, Greg Ward wrote:
> On Mon, Mar 1, 2010 at 6:31 PM, Adrian Buehlmann <adrian at cadifra.com> wrote:
>> If shortly tried to think about how it is possible to force duplicate
>> entries in the fncache file with the current code and failed. But I
>> could swear I saw it in the past. tonfa has made some nice refactorings
>> in store.py though in the past, which IMHO seem to make it harder to get
>> duplicates. Do you happen to know a use case that produces duplicate
>> lines in fncache? (I guess I'm too lazy right now to see it)
>
> Well, we must be missing something. I just re-ran the same cvs2hg
> conversion three times, with hg 1.3, 1.4, and 1.5ish (current stable).
> Result: highly redundant fncache every time.
>
> Specifically, in every case:
> * the new hg repo created by cvs2hg has 3741 files in .hg/store/data
> * there are 3875 unique lines in .hg/store/fncache (sort -u | wc -l)
> * there are 28354 total lines in .hg/store/fncache
>
> Based on that, I conclude that strip's runtime will be dominated by
> the time taken to read fncache for any repo created by cvs2hg with
> Mercurial 1.3, 1.4, or 1.5. ;-(
Does http://selenic.com/repo/hg-stable/rev/d5bd1beff794 improve this?
More information about the Mercurial-devel
mailing list