Jakub Narebski wrote:
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.
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).
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.
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
