Re: [PATCH] Implement limited context matching in git-apply.

[Junio C Hamano <junkio@cox.net>]

ebiederm@xmission.com (Eric W. Biederman) writes:

> If I just loop through all of Andrews patches in order
> and run git-apply --index -C1 I process the entire patchset
> in 1m53s or about 6 patches per second.  So running
> git-mailinfo, git-write-tree, git-commit-tree, and
> git-update-ref everytime has a measurable impact,
> and shows things can be speeded up even more.

Although I haven't "read" it, but just only "looked at" it, the
patch looks OK.  I haven't managed to start beating on it yet
for time constraints.

If you are dealing with the kernel tree, I suspect most time is
spent on write-tree.  Statistically, a typical kernel patch (I
haven't counted the ones in -mm series, but only the ones
actually reacheable from Linus tip) touches only 3 files on
average, so most of the 1,100 tree objects in a typical kernel
tree are computed but found unchanged when write-tree happens.

I suspect we could make a backward incompatible change to the
index file format to record the top-level tree object names
somewhere where normal cache-entry walker would not see.  Then
when anybody makes a modification to invalidate that tree
object, mark that tree (or split that tree to read lower level
trees lazily) to force us recompute the tree object.

Theoretically you could do that recursively to record all 1,100
tree objects but that would make the cache slightly larger (say,
by 100kB).