On 29 July 2016 at 00:38, Junio C Hamano <gits...@pobox.com> wrote:
> Øyvind A. Holm <su...@sunbase.org> writes:
> > Jakub Narębski <jna...@gmail.com> wrote:
> > > I wonder if using `git worktree` instead of `git clone` (well,
> > > local clone uses hardlinks, so it is not that costly as it looks
> > > like) would be a better solution.
> >
> > That's an interesting idea. Have to test it out. This is the result
> > from the current master in linux.git:
> >
> > With clone:
> > ...
> > With worktree:
> > ...
> >
> > Both tests were run with cold cache ("echo 3
> > >/proc/sys/vm/drop_caches" as root). It seems as there's no
> > >difference, and that git clone is as fast as it can get without
> > >breaking physical laws. And we probably shouldn't do that. :)
>
> I expect that writing the 55k+ files in the working tree would
> dominate the cost.  Local clone would make some hardlinks in .git
> (including ones in .git/object/*) but the cost of that would not be
> too high as long as the repository is well packed; "git worktree"
> would reduce that part of the cost from "git clone", but both incur
> the cost of "checkout", i.e. actually populating the new working tree.
>
> Does the test directory even need to look anything like Git?  In other
> words, would it suffice if it resembled the result of running "git
> archive | tar xf -"?  I suspect that it would not make much
> difference, either, for the same reason, though ;-).

Using git archive saved 1.6 seconds:

  $ mkdir testdir; git archive HEAD | (cd testdir && time tar x)

  real    0m8.881s
  user    0m0.440s
  sys     0m2.740s
  $

But when .git is missing in the subdir, git apply doesn't work. Can't
think of any way to get that to work without involving patch(1) and
friends, and then the binary diffs goes out of the window.

But I'm quite satisfied with 10.4 seconds with cold diskcache and >55K
files. Very impressive, actually.

- Øyvind
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to