On Fri, Jul 27, 2018 at 6:22 PM Ben Peart <peart...@gmail.com> wrote: > > > > On 7/27/2018 11:42 AM, Duy Nguyen wrote: > > On Thu, Jul 26, 2018 at 12:40:05PM -0700, Junio C Hamano wrote: > >> Duy Nguyen <pclo...@gmail.com> writes: > >> > >>> I'm excited so I decided to try out anyway. This is what I've come up > >>> with. Switching trees on git.git shows it could skip plenty entries, > >>> so promising. It's ugly and it fails at t6020 though, there's still > >>> work ahead. But I think it'll stop here. > >> > >> We are extremely shallow compared to projects like the kernel and > >> stuff from java land, so that is quite an interesting find. > >> > > > > Yeah. I've got a more or less complete patch now with full test suite > > passed and even with linux.git, the numbers look pretty good. > > > > Ben, is it possible for you to try this one out? I don't suppose it > > will be that good on a real big repo. But I'm curious how much faster > > could this patch does. > > > > Thanks Duy. I'm super excited about this so did a quick and dirty > manual perf test. > > I ran "git checkout" 5 times, discarded the first 2 runs and averaged > the last 3 with and without this patch on top of VFSForGit in a large repo. > > Without this patch average times were 16.97 > With this patch average times were 10.55 > > That is a significant improvement!
Meh! Junio cut down time to like 1/5th in b65982b608 (Optimize "diff-index --cached" using cache-tree - 2009-05-20). This is not enough! OK i'm kidding :) I'd like to see you measure traverse_trees like in your first mail though. Total checkout number is nice and all but I still like to see exactly how much time is reduced in traverse_trees() alone (or unpack_trees() to be precise). That would give me a much better picture of this unpacking business. -- Duy
