[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: ideas to make svn update faster.

From: Folker Schamel <schamel23_at_spinor.com>
Date: 2005-05-08 19:53:50 CEST

Some additional notes:
Performance under windows really is a serious problem;
it is much worse than under Linux due to the windows file system.
My impression is that unix-only-users often are not aware of this.
My personal experience is: what costs only seconds under Linux
often costs a minute under windows (e.g. a svn status; but strongly
depending on the current state of the file system cache,
which is worse under windows).

And there's another fundamental difference between windows
and linux: The Tortoise performance is really critical,
because it is integrated into the windows explorer itself.
I am not aware of something similar on Linux.
A command line command hanging for some time is one thing.
But the windows explorer itself hanging for several seconds is another.
The performance of the tortoise shell extension probably is the most
critical performance issue compared to all other svn clients.

This is the reason why I really don't like suggestions for performance
"optimizations" without being aware of Tortoise or not using windows
at all. ;-) Linux is really cool, but it is a fact that far the biggest
market share is windows. At the end it is one reason for the success
of svn that svn has a really good windows support.

> Philip Martin wrote:
>
>> Folker Schamel <schamel23@spinor.com> writes:
>>
>>
>>> And Tortoise queries the wc status non-recusively, which then would
>>> have to go up to root all the time instead of a single file read,
>>> as already explained by Philip.
>>> Which translates into multiple times slower.
>>
>>
>>
>> It will make it slower, but not multiple times slower. Non-recursive
>> status already reads entries files for immediate subdirs and the
>> immediate parent.
>
>
> Immediate subdirs also in case of the status of a file?
>
> > It also does a lot more than just read entries
>
>> files. However changing it to read entries files all the way back to
>> the root must, in general, make it a bit slower.
>
>
> Of course the actual costs depends on your particular situation.
> It is pure speculation, but for example in our particular case
> we have a quite deep directory structure (and not too many
> immediate sub-dirs), and so I suppose Tortoise would be really
> multiple times slower.
>
> But what I really wanted to point out:
> As far as I know, currently the costs depend only _locally_ on
> the project directory structure. But then it would depend on the
> tree depth of the _global_ structure of the project.
> Which I consider as bad scaling behaviour for large projects,
> because it is somehow a change from O(1) to O(log project_size).
> Maybe the wording was choosen badly, but this is what I wanted
> to express with "multiple times slower".
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun May 8 19:54:46 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.