On 5/9/07, David James <james@cs.toronto.edu> wrote:
> On 5/9/07, Daniel Berlin <dberlin@dberlin.org> wrote:
> > On 5/9/07, David James <james@cs.toronto.edu> wrote:
> > > On 5/9/07, Daniel Berlin <dberlin@dberlin.org> wrote:
> > > > [... snip ...]
> > > > Yeah, it may slow down if you log obscure directories with almost no
> > > > changes. But i don't believe this is the common case.
> > >
> > > How dramatic is the slowdown from your optimization if you run 'svn
> > > log' on a file or directory which has few changes? From reading your
> > > email, it seems like the slowdown will be very minor, but correct me
> > > if I am wrong.
> >
> > Minor, because discover_changed_paths will see there is nothing there
> > *really* quickly (should be O(1), i think)
> >
> > It's just you are going to have say, 10-20 more O(1) calls that take a
> > few milliseconds.
> >
> > >
> > > I do often run 'svn log --limit N' on an individual file or directory
> > > to read about the last N changes to a particular file or directory. I
> > > also find it handy to run "svn log -r1:HEAD --limit 1 --stop-on-copy"
> > > to find the last revision in which a file was copied, or "svn log
> > > -r1:HEAD --limit 1" to find the revision in which a file was created.
> > > So far I haven't noticed any performance problems with these
> > > operations, but if your change will have a dramatic effect on these
> > > cases you might want to think about that.
> >
> > If you haven't had performance problems, you haven't tried it on a
> > large enough repo. My suggestion would should make those commands
> > very slightly slower. Let's say you had a million revision, and we
> > picked a batch size of 20000.
> >
> > If the file was changed 4 times, and all in the last 20k revisions, we
> > will have 49 useless calls (1-20k, 20k-40k) taking O(1) time each.
> > If the file was changed 4 times, spread evenly among the batches, we
> > do the same amount of work we used to.
> > If the file was changed thousands of times, spread evenly among the
> > batches, we do a lot less work than we used to.
> >
> > I expect some combination of 2 and 3 is the common case. Even for 1,
> > it shouldn't drop the performance very much.
>
> Great! In that case, +1 on the optimization. It sounds like it will be
> very helpful when users need to grab the revisions in reverse order
> for a big repository.
Actually, you have it backwards
It will be very helpful when they grab the revs in normal order.
When they ask for the revs in reverse order we can already stream it :)
>
> Cheers,
>
> David
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 10 00:58:40 2007