Re: some performance data

solo turn <soloturn99@yahoo.com> writes:

> $ ls -lR1 | wc
> 27169 180954 1577289
> $ ls -lRa1 | wc
> 308013 1945643 16999068

Isn't this counting .svn areas too, which are full of files?

> $ du -sk
> 377130 .

And this as well?

> $ date && svn up && date
> Fri Jan 10 17:27:38 2003
> At revision 302.
> Fri Jan 10 17:29:57 2003
>
> updating on a p4 is quite a hit on a p4 with fast ide disk for more
> than 2.5 minutes, with 25000 files/dirs versioned, including
> tags/branches.

So your working copy was fully at HEAD, and it took 2.5 minutes to
traverse 25000 files/dirs?

All that svn had to do was read every entries file exactly once, and
noticed if you had any mixed revisions. Once it determined you
didn't, it sent a single REPORT http request that said "I have
everything at revision 302", and the server response should be nearly
empty, saying "no need to change anything.

So the network shouldn't have been the issue here. To verify this,
can you run an ethereal trace and see if the final REPORT
request/response is as small as I expect?

Assuming that's true, why does it take so long to read all those entry
files? For example, when I run 'svn up' on my svn tree, it takes 1.4
seconds:

[sussman@kepler:~/projects/svn]$ time svn up
At revision 4322.

real 0m1.415s
user 0m0.136s
sys 0m0.112s

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jan 10 18:47:48 2003