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

Re: log -g performance

From: David Glasser <glasser_at_davidglasser.net>
Date: Tue, 17 Jun 2008 13:36:53 -0700

On Tue, Jun 17, 2008 at 7:51 AM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> Leonardo Fernandes wrote:
>> Hi.
>> I just wanted to know why log -g operations are much slower than normal
>> log, even when the revisions don't have any merge-info change?
> I suspect this is just the overhead of checking -- for each revision --
> whether or not the revision has a mergeinfo change. This penalty is small
> where no mergeinfo exists at all, but gets larger once mergeinfo appears in
> the repository (and grows depending on the depth, directory-wise, of the
> places where mergeinfo is set).
> (Is that right, David?)

I don't actually know much about log -g (other than making sure that
the APIs it used at one point existed); Hyrum probably has more
insight here.

> I think we could improve this by changing the way we detect these
> differences. Today, we do so by fetching all the mergeinfo in one revision,
> then all the mergeinfo in another revision, and then comparing them. We'd
> probably be better served by adding an svn_fs_mergeinfo_diff() function that
> could avoid crawling into unchanged regions of the respective revision trees
> to even find mergeinfo (since the mergeinfo found in both subtrees would be
> identical, and thus not present in a diff of the two anyway).

That wouldn't be too tough to implement and, if you're accurately
diagnosing the problem, would probably help a lot.


David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-06-17 22:37:09 CEST

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.