Grrr.... web mail lost my attachment! Here it is. Sorry.
============================
In my testing of 1.1rc1 on windows (W2K SP4), I've noticed a big performance
regression on 'svn status'. I'm not sure if this behaviour occurs in other
commands, but I've examined svn status in some detail.
I have a large repository that contains about 5000 files, with some
directories containing hundreds of files. When I do an 'svn status' I get
the following results:
SVN 1.0.6: ~ 4 secs
SVN 1.1rc1: ~ 38 secs !!
I used the Filemon utility from sysinternals to try to determine what it
happening. It looks like 1.1 excessively hits 'iconv' files. (e.g.
windows-1252.so, utf-8.so, etc)
In 1.0 it appears to hit these files early in the process, but then doesn't
touch them while checking the *.svn-work and *.svn-base file.
In 1.1 however for *every* hit on *.svn-work, etc you get multiple hits to
various iconv file. They always accessed in the following order:
* cp1252.so (attempted open once, not found)
* windows-cp1252.so (opened, closed, stat'd 3 times)
* _tbl_simple.so (opened, closed, stat'd 3 times)
* cp1252.so (attempted open once, not found)
* windows-cp1252.so (opened, closed, stat'd 3 times)
* utf-8.so (opened, closed, stat'd 3 times)
It seems that this is the thing killing performance.
I've attached a zip file with the repro script (that creates a 16 file
repository) and the output from filemon for the 'svn status' with both 1.0
and 1.1. You can even see from the size of the 1.1 file that it does *a
lot* more work.
(Hopefully I haven't done anything stupid in my setup that make 1.1rc1
behave this way! I made sure that the iconv path env variable was set to
the right location. Let me know if you need more info to track this one
down. I'm happy to help).
Regards,
Matt Doran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 5 04:29:15 2004