Sebastian Tusk wrote:
> 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.
You don't say if your file has svn:eol-style or svn:keywords properties.
I'm assuming it does.
>
> 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
This is probably "detranslate". We should be skipping this part if the
file doesn't have svn:eol-style or svn::keywords properties.
With the change on trunk that replaces detranslation to a temporary file
with a detranslating stream, these writes should go away.
> ------
> read 102400b blocks from "test.svn-base"
> write 4096b blocks to "temp.tmp"
> occasionally other reads from "test.svn-base" COPY? DIFF? 2m23s
"Delta" on the detranslated file. Again, we could probably get rid of
the read if we simply use a detranslating stream.
> ------
> read 512b blocks from test.svn-base HASHING? 1m47s
Possibly hashing, yes... dunno.
> ------
> read 4096b blocks from "tempfile" TRANSFER TO SERVER 7m8s
> ------
> read 512b blocks from "test.svn-base" HASHING? 1m16s
Hm. If that's hashing again, it should go away.
> ------
> 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
I don't understand these last entries.
>
> 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.
As I said, we could probably get rid of some of the reads and writes
(and I believe we have done so, on trunk). The fact that we read such
small blocks is definitely a bad thing.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 8 15:45:30 2006