Hi Stefan,
Thanks for your quick response.
Stefan Küng wrote:
> Nathan Kidd wrote:
>> I just did a command-line 'svn up' in a sizable working copy (21,000
...
>> browsing in explorer was quite slow to respond.
>
> That's not a surprise.
> When you don an 'svn up', disk activity is really high, not just because
> of the TSVN cache but because of the actual update. In that case,
> explorer will react very slowly, because explorer itself reads every
> file it shows. And if disk activity is high, that's slow.
I failed to say: This explorer browsing was in a completely different
WC, for a different repository, but on the same disk. Is it still expected?
> There are in fact several (6) different threads in the cache, each with
> its own function to take care of.
> And as you already want it: the thread handling status requests from the
> explorer has the highest priority - all other threads have either "idle"
> or "below normal" priority.
Indeed, Spy++ (which I should have thought of earlier) shows a total of
nine threads, most of which have base priority 8, but two threads have
base priority 6 -- these must be the status threads (?). I noticed
though, that the *current* (not base) thread priorities seems to change
around a bit while the crawler is running. Is it remotely plausible
that the priorities might be getting set un-optimally during runtime?
-Nathan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Mon Jan 9 20:50:30 2006