On Sun, 8 Jun 2008, Lea Wiemann wrote:
quoted text
> On Wed, 04 Jun 2008, Lea Wiemann wrote:
>>
>> Blame first calculates the whole blame and then dumps it out in
>> zero-time [so] there's no performance difference in getting all  blame
>> output and then dumping it out vs. reading and outputting it line-by-line.
> 
> I haven't been following the recent discussion in detail, but here's 
> another thought: If you want to look up the parents, it's usually faster 
> (at least when caching is enabled) to get them all in a single call. 
> IOW, don't look up the parent for each hash as it appears, but collect 
> all hashes and then get a list of all parents with a single call.

If caching is enabled, then parent info can be retrieved from cache.
If caching is disabled, or cache expired (cache miss) you would have
to get whole blame output to get all revisions to get parents for.
This means for a short while twice amount of memory (whole blame in
git-blame, because thats how non-incremental blame works, and whole
blame in gitweb, till reading last byte of blame when git-blame ends);
and that is not good when memory-based cache (be it memcache, mmap,
or other solution) is on the same machine (sometimes you just don't
have a farm of servers...).

Junio's patches adding "previous" header to git blame result in no
worse output (result) than current code.  I have proposed improvements,
but I'm not sure they can be implemented cheaply (fairly sure that they
cannot, and I'm not sure if improvements are worth the cost).  I'd like
to know what happens in Junio code when evil merge is blamed; I don't
know code enough (and I am a bit lazy here) to get this from code
itself.

-- 
Jakub Narebski
Poland
--
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