Re: Bizarre missing changes (git bug?)

From: Roman Zippel <zippel@linux-m68k.org>
Date: Jul 30, 2008, 01:14 UTC
Message-ID: <Pine.LNX.4.64.0807300223010.6791@localhost.localdomain>
In-Reply-To: <alpine.LFD.1.10.0807290838360.3334@nehalem.linux-foundation.org>

Hi,

On Tue, 29 Jul 2008, Linus Torvalds wrote:

Show 14 quoted lines

> On Tue, 29 Jul 2008, Roman Zippel wrote:
> > 
> > I'm not dismissing it, but your focus is on how to get this result.
> 
> No, you misunderstand.
> 
> My focus is really on one single thing:
> 
>  - performance
> 
> with a smaller focus on the fact that I simply don't see how it's 
> _possible_ to do better than our current all-or-nothing approach of 
> simplification (eg either extreme simplification or none at all: nothing 
> or --full-history).

That's exactly what I'm not dismissing as you claim, but I've hit the problem where this approach simply produces crap, so I'm foremost interested in getting a useful result, only after that I'm interested in the performance (which I think is possible).

Show 7 quoted lines

> So here's my challenge again, which you seem to have TOTALLY MISSED.
> 
> Make this be fast:
> 
> 	time sh -c "git log <filename> | 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).

> 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.

Show 7 quoted lines

> > > And quite frankly, I've seen that behaviour from you before, when it comes 
> > > to other things.
> > 
> > What exact behaviour is that? That I dare to disagree with you?
> 
> No. The fact that you like arguing _pointlessly_, and just being abrasive, 
> without actually helping or understanding the big picture.

The problem is that your picture doesn't include my specific problem, I'm very interested in the big picture, but I'd like to be in it.

> I'm thinking 
> back on the whole scheduler thing. You weren't arguing with _me_, but you 
> had the same modus operandi.

Well, it seems I have talent for finding the special cases, e.g. last time I tested the scheduler it was performing twice as bad as the old scheduler on m68k. I've also seen cases where it sacrifices throughput for interactivity. Anyway, this is the wrong place for it anyway, the problem I'm hitting is these "good enough" solutions, which work in most situations, but fail in a few special situations, but nobody is interested to get these right unless your name is Linus.

bye, Roman