On Sun, 8 Jun 2008, Lea Wiemann wrote: > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
