On Mon, 2005-02-14 at 14:34 +0100, Peter N. Lundblad wrote:
> On Sun, 13 Feb 2005, Daniel Berlin wrote:
>
> >
> > > It depends on your repository, but probably yes.
> > >
> > 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
> >
> >
> > 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).
> >
> OK. Here we go. On my tests it is a big speedup. I tested on FSFS with and
> without xdelta when the dump was loaded. It seems like we win a lot even
> if vdelta was used to create the repo. Anyway, feel free to fill in the
> missing row above:-)
Okay, i noticed a problem with this patch after a lot of testing, and
trying to figure out why on ChangeLog, copy_source_ops was still at the
top of the list for fsfs.
It then hit me in the shower.
ChangeLog is > SVN_DELTA_WINDOW_SIZE when deltified, and you only
auto-expand the first window. However, the entire file is vdelta'd,
which means all of the windows. So the other windows with target ops
get combined, causing quadratic behavior again on this file.
I'm completely in law mode right now, so nothing pops into my head as a
good solution for this problem.
--Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Feb 22 02:38:36 2005