ebiederm@xxxxxxxxxxxx (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). - : send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html