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
Received on 2011-02-03 18:01:53 CET