On 19.10.2017 10:07, Thomas Singer wrote: > On 2017-10-19 9:05, Branko Čibej wrote: >> On 19.10.2017 08:30, Thomas Singer wrote: >>> On 18.10.2017 19:56, Branko Čibej wrote: >>>> On 18.10.2017 13:31, Thomas Singer wrote: >>>>> Hi, >>>>> >>>>> When performing following steps on my old Linux test machine (with >>>>> slow hard disk): >>>>> >>>>> - have a SVN working copy at /home/user/test >>>>> - sudo apt install nfs-kernel-server >>>>> - add following line to /etc/exports: >>>>> /home/user/test *(rw,sync,no_root_squash) >>>>> - start the NFS server: >>>>> sudo systemctl start nfs-kernel-server.service >>>>> - mount the NFS share: >>>>> sudo mount localhost:/home/user/test /home/user/test.nfs >>>>> >>>>> and then open /home/user/test.nfs in SmartSVN 9.2 (using SVN 1.9 >>>>> JavaHL binaries), adding/removing a file is very slow. It boils down >>>>> to the call ISVNClient.getChangelists which takes ~8s on the NFS >>>>> share >>>>> (/home/user/test.nfs). First, I thought, it would be caused by the >>>>> native-Java overhead calling the call-back ~11,000 times for my >>>>> working copy, but when using the working copy directly >>>>> (/home/user/test), the method just takes <1s though the ~11,000 times >>>>> call-back invocations are still there. >>>>> >>>>> My working copy has no local modifications, no untracked or ignored >>>>> files, no changelists. >>>>> >>>>> Is it expected that this method (ISVNClient.getChangelists) is so >>>>> slow >>>>> on a NFS share even if there are no changelists? >>>> >>>> I don't know if it's "expected" but I bet that NFS is killing SQLite >>>> performance. >>>> >>>> https://www.mail-archive.com/sqlite-users@mailinglists.sqlite.org/msg88989.html >>>> >>>> >>>> >>>> I'm not sure about the reason but the most likely answer, apart from >>>> slow data rate and latency when compared to a local filesystem (which, >>>> in your case on loopback, should not be an issue), is that the OS >>>> can't >>>> really use a cache for files on NFS since it has no way to know >>>> whether >>>> or not it's valid. With a lot of random-access reads and writes, that >>>> can be a HUGE slowdown, as you found. >>>> >>>> >>>> Also this: >>>> https://sqlite.org/faq.html#q5 >>>> >>>> In other words, Subversion working copies on NFS are, and have always >>>> been, a bad idea; not only because of SQLite but also because >>>> Subversion's code itself relies on atomic renames, which NFS does not >>>> provide. >>>> >>>> -- Brane >>> >>> What SVN command (on command line) I should test to get a similar >>> result as from ISVNClient.getChangelists? >> >> If "adding/removing a file" is any indication, then "svn add" or "svn >> remove" should be comparable. > > Sorry, this was misleading. Adding/removing a file cause a refresh of > which ISVNClient.getChangelists takes the longest time. With SmartSVN > Foundation ISVNClient.getChangelists is not invoked and hence much > faster when refreshing after a command, e.g. add or remove. > > Which is the SVN command line equivalent of ISVNClient.getChangelists?
The only one I can find that actually uses the svn_client_get_changelists() function is 'svn update --changelist', but of course it also does an update, so the comparison is not entirely valid. -- Brane