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