[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Making blame even faster

From: Daniel Berlin <dberlin_at_dberlin.org>
Date: 2005-02-13 21:17:52 CET

> It depends on your repository, but probably yes.
> -- Brane

Just to followup:

Brane's timings on windows showed that for the gcc combine.c file (which
had ~1500 revisions, spread out across branches, etc), we had

blame on an bdb repo with vdelta: 40 seconds
blame on an bdb repo with xdelta: 10 seconds

blame on an fsfs repo with vdelta: 108 seconds
blame on an fsfs repo with xdelta: 105 seconds

I have mostly the same experience *except* thta blame on an fsfs repo
with xdelta with the patch that was committed was a bit faster than that
(maybe 10 seconds faster)).

To fully take advantage of the xdelta speedup on fsfs, you need to
implement greg hudson's suggestion of making sure the vdelta rep against
empty is *not* combined with other windows, or be willing to give up the
first rep being compressed (IE it will store one fulltext in the repo).

With that change in place, you will get numbers roughly the same on fsfs
and bdb.

I can provide a patch that makes the first delta against empty a
fulltext in fsfs as a temporary solution if you really need a fast blame
and can't wait for Greg Hudson's solution to be implemented and tested.

I should note that i've tried to implement what he proposed, but have
run into problems because the current code tries to seek the src_state,
and other things, so it's not an dead easy conversion to making it a
stream (which is what we really want).


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Feb 13 21:19:09 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.