I did some tests with a repository that contains a single file sized 686
MB. I used the svn client version 1.3.0 on a windows machine.
svn commit 1587s
svn export 136s
svn co 395s
To me this figures appeared way to high. It seems that most of the time
is used up in disk activities so I had took a look at that.
svn commit
The file to commit is named test. The function performed is guessed.
activity function? time
------
read 512b blocks from "test"
write 512b blocks to "test.svn_base.tmp" COPY? 3m10s
------
read 102400b blocks from "test.svn-base"
write 4096b blocks to "temp.tmp"
occasionally other reads from "test.svn-base" COPY? DIFF? 2m23s
------
read 512b blocks from test.svn-base HASHING? 1m47s
------
read 4096b blocks from "tempfile" TRANSFER TO SERVER 7m8s
------
read 512b blocks from "test.svn-base" HASHING? 1m16s
------
read 512b blocks from "test"
read 512b blocks from "test.svn-base" COMPARE? 7m46s
------
read 512b blocks from "test.svn-base"
write 512b blocks to "test.tmp.tmp"
occasionally other reads from "test.svn-base" COPY? 3m12s
------
read 512b blocks from "test"
read 512b blocks from "test.tmp" COMPARE? 7m42s
That are all activities that consume significant time. All reads and
writes are over the full 680MB file. Only during TRANSFER TO SERVER
there is any noticible server activity. Alltogether the commit command
uses more than 13 million read or write operations.
Are all this activities necessary? Especially those after the transfer
to the server is finished. Is it necessary to access two files in
parallel in such small blocks? Using larger read/write blocks might
improve the performance significant without to much hassle.
Sebastian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 7 13:47:55 2006