On Thu, Feb 03, 2011 at 04:18:32PM +0000, Neil Bird wrote: > > This is a patch for discussion which I submitted to issue 3719 > (“Extremely slow checkout on Windows”). I shan't repeat everything > that's there; essentially it fixes *really* slow checkouts to NTFS > of directories with large numbers of files with properties. > > > I originally modified it slightly to address my second comment on > that issue, namely that just using rand() will leave it with > slightly less functionality than the previous 99999 loop. > > However, that was relying upon my Linux man page telling me > RAND_MAX was 32767; it's actually 2147483647. I think it's still > smaller on Windows, though, so it would suffer that limitation. > Should we include a small, custom int-max rand() just for this? > > Otherwise it might be a #if on RAND_MAX. > > > A supplementary question is: should I worry about where rand() is > included from? It “just worked” on my Linux build, but I've not > tried for Windows, etc. > > > Apologies if I haven't formatted all this correctly. > > > [[[ > Fix issue #3719: prevent logarithmic slow down when checking out > large directories onto Windows NTFS > > * subversion/libsvn_subr/io.c > svn_io_open_unique_file3: don't call svn_io_open_uniquely_named(), > but instead use a copy of that routine
Which routine, precisely? > that uses rand() to get the > next potential free number instead if simply incrementing, > minimising clashes on repeated calls. Have you taken a look at the implementation of svn_io_open_unique_file3() in Subversion's trunk code? This has already been changed, and it looks like it already solves the performance problem. It also has a special case for windows -- see the temp_file_create() helper function. I think it would be better to backport that code to 1.6.x, instead of changing svn_io_open_unique_file3() for 1.6.x in some other way. Stefan
