On Tue, Oct 2, 2018 at 5:37 PM Bert Huijben <b...@qqmail.nl> wrote: > On Tue, Oct 2, 2018 at 4:30 PM Branko Čibej <br...@apache.org> wrote: >> >> On 02.10.2018 02:38, Johan Corveleyn wrote: >> > I haven't looked deeply into it yet, but it seems that the >> > conflicts-tests (the C tests) are very slow when testing over >> > svnserve. I noticed this while testing 1.11.0-rc2, but I see the same >> > with trunk and with 1.10.x. >> > >> > Running the entire conflicts-test.exe (on a ramdisk): >> > - ra_local: 23s >> > - ra_serf: 70s >> > - ra_svn: 982s (16m22s) >> > >> > The difference between ra_local and ra_serf strikes me as normal >> > (after all, the conflict resolver contacts the repository a lot to >> > fetch information). The time of ra_svn not really :-). >> > >> > The slowdown seems to be spread over all the tests of conflicts-test >> > (the dots of the test progress come evenly spread). >> > >> > Is anyone else seeing this? Only on Windows, or on *nix too? >> > A performance problem with tree conflict resolution specific to svnserve? >> >> How do you set the URL for win-tests.py? I've noticed that using >> svn://localhost is orders of magnitude slower than svn://127.0.0.1, >> apparently because the Windows resolver attempts a DNS search for >> 'localhost' first (and failing) before resolving it locally. >> >> -- Brane >> > It resolves to both ::1 and 127.0.0.1 on Windows, and as (per RFC) ipv6 is > tried before ipv4... things timeout before trying the address used by default > (hardcoded) in svnserve. > (We used to default to ipv6 for some time... But we decided to explicitly > default to ipv4 when not passing the later added -6) > > More recent Windows versions have a workaround/speedup for this problem. They > will swap the DNS results after a few failed attempts. > > Bert
Yep, that's it. Thanks all. When using svn://127.0.0.1 conflicts-test.exe takes around 28s for 1.11.0-rc2 on my machine. Much better :-). -- Johan
