hg slow on large repo

Benjamin LaHaise bcrl at kvack.org
Wed May 23 22:34:02 UTC 2007


On Wed, May 23, 2007 at 04:53:37PM -0500, Matt Mackall wrote:
> Can you please try the untar test? If untar is slow, we know we have
> OS or FS issues.
> 
> If untar is significantly faster than update, we have a problem.

Untar took 4m30s from a compressed tarball of the repository + checked out 
tree.  There are about 100,000 file in the tree.

> I'm assuming this is an ext3 filesystem. Do you have atime updates
> disabled? What size is your journal?

atime updates are disabled.  The journal is the default size for a 100GB 
filesystem (can't get to the machine at the moment).

> > git seems to get through this much more quickly with -l as it only has to 
> > deal with just one large .pack file which can be read sequentially.
> 
> What's -l? If you have atime enabled, git will win simply because it
> has only one atime to update.

-l uses hardlinks for the repository like hg does.

> No. Nor does git. Unless git is somehow segregating all of the data
> needed to checkout tip in some localized subset of the pack, it will
> have to visit more or less the whole pack on checkout. And if you've
> got multiple packs, it will have to visit them all more or less
> randomly to find files last touched in various epochs.

It's 1 pack plus a hundred or two objects in smallish files.

		-ben
-- 
"Time is of no importance, Mr. President, only life is important."
Don't Email: <zyntrop at kvack.org>.



More information about the Mercurial mailing list