From: Kevin Ballard Date: Wed, 30 Jul 2008 01:32:14 GMT Subject: Re: Bizarre missing changes (git bug?) Message-ID: <3B2566EF-807E-46E6-8447-D13A5904F00C@sb.org> In-Reply-To: On Jul 29, 2008, at 6:14 PM, Roman Zippel wrote: >> So here's my challenge again, which you seem to have TOTALLY MISSED. >> >> Make this be fast: >> >> time sh -c "git log | head" >> >> nothing else matters. If you can make that one be fast, I'm happy. > > I already explained it, but you simply dismissed it. It's possible, > but it > requires a bit of cached information (e.g. as part of the pack file, > which > is needed for decent performance anyway). As an outside observer, this argument is basically akin to "it's easy to fly, you just need some faerie dust". Basically, you're dismissing the entire complexity of the problem by saying "oh, that's easy, just use some cached data" without any proof that this would work, or any sample code, or really any evidence at all. Given that the path simplification can be arbitrarily complex (I can pass any set of paths I want), I don't believe that you can just use "a bit of cached information" for this. If you did rely on cached information, said information would probably be orders of magnitude larger than the object graph itself (for repos with lots of files). >> In fact, you can see what I'm talking about by trying --topo-order >> in the >> above timing test. > > Please give me full example. > gitk --topo-order kernel/printk.c shows no difference (e.g. it doesn't > show 02630a12c7f72fa294981c8d86e38038781c25b7), several experiments > with > git-rev-list show no improvement either. He's not saying it changes what commits are shown, he's saying it has a performance impact - topo order has to post-process the graph. For a quick demonstration, run `time sh -c 'git log | head'` vs `time sh -c 'git log --topo-order | head'`. -Kevin Ballard -- Kevin Ballard http://kevin.sb.org kevin@sb.org http://www.tildesoft.com