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

Re: [PATCH] The blame speedup, second try

From: Peter N. Lundblad <peter_at_famlundblad.se>
Date: 2004-06-01 20:37:51 CEST

On Mon, 31 May 2004, Ben Collins-Sussman wrote:

> On Mon, 2004-05-31 at 15:26, Peter N. Lundblad wrote:
>
> > I've reworked the patch, so that the file_rev_handler takes a delta stream
> > instead of the name of a temporary file. Also, I created a repos function
> > matching the RA layer one. libsvn_client/blame.c is a real mess currently.
> > Obviously, I'll clean it up before you'll se its commited.
> >
> Question: is 'svn blame' measurably faster with this optimization? Or
> is it impossible to measure right now, since you only have it working
> with ra_local?

You answered your own question. I'm not expecting a big speedup in
ra_local, but a little one since we don't need to fetch the cnaged_path
info for each revision. ON the other hand, calculating and applying deltas
slow it down, but I'm not sure if this is a problem worth working on.

I expect one network roundtrip with deltas to be faster than N (for N
revisions) roundtrips with fulltexts, however. But, as you say, actual
measurement is relevant. I guess I have to do one network layer to be able
to test. The problem is that testing this locally is no good, since it
will probably be similar to the ra_local case. Ofcourse, I can view
transfer statistics on the loopback device, but that doesn't talk about
network latency.

Unfortunately, I have no remote machine to setup a test repository on. The
slow link, I have, however. So if anyone would be willing to temporarily
host a patched server...

Regards,
//Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jun 1 20:28:49 2004

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.