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.
>
> Cheers,
>
> David
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 9 19:51:36 2007