Jakub Narebski wrote:
quoted text
> I don't think %parent_commits hash is suitable for caching; it is only
> intermediate step, reducing number of git command calls (and forks) [...]
> 
> ATTENTION! This example shows where caching [parsed] data have problems 
> compared to front-end caching (caching output).

ATTENTION!  Could we please stop having this discussion?!  Your argument 
is completely bogus.  If the parent commit hashes are in cache, it's an 
almost zero-time cache lookup.  The only difference it might make 
compared front-end caching is the CPU time it takes to generate the 
page, and *I want to see benchmarks before I even start thinking about 
CPU*.  Okay?  Good, thanks.

Sorry I'm a little indignant, but you seem to be somehow trying to tell 
me what to implement, and that gets annoying after a while.  I don't 
mind your input, but at some point the discussion just doesn't go any 
further.

quoted text
> Problems occur when we try to cache page with _streaming_ output, such 
> as blob view, blame view, diff part of commitdiff etc.

We can still stream backend-cache-backed data, though it's a little 
harder.  It's mostly a memory, not a performance issue though -- the 
only point where I think it actually would be performance-relevant is 
blame, and blame doesn't stream anyway (see below).

quoted text
> By the way, if we agree that version %parent_commits is too intrusive 
> dusring GSoC 2008,

Oh, I don't mind, FTR.  It's not enough lines to matter.

quoted text
>> 2) Major point: You're still forking a lot.  The Right Thing is to
>> condense everything into a single call
> 
> This is not a good solution for 'blame' view, which is generated "on the 
> fly", by streaming git-blame output via filter.

No, whether you have your "while <$fd>" loop or not doesn't make a 
difference.  Blame first calculates the whole blame and then dumps it 
out in zero-time, unless you use --incremental.  So there's no 
performance difference in getting all blame output and then dumping it 
out vs. reading and outputting it line-by-line.  And regarding memory, 
if your blame output doesn't fit into your RAM, you have different kinds 
of issues.

JFTR, I don't have any opinion about extending the porcelain output of 
git-blame (apart from the fact that happens to not be useful for gitweb 
for the reason I outlined in the previous paragraph).

-- Lea
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html