Stefan Fuhrmann wrote:
> ever since, I experienced delays in the Explorer
> as soon as TSVN is installed. For a long time,
> I blamed our IT setup for these effects. But now,
> while corporate IT seems to have a fair share in
> that matter, it looks like TSVN is actually the
> one triggering it.
>
> * Showing the context menu or opening a folder
> in the Explorer takes 1..2 additional seconds.
> This is fine with me as long as it remains in
> that order of magnitude.
That's because TSVN asks for the status of the right-clicked item before
showing the menu.
> * Being disconnected from the LAN, the same operations
> lock up for about 10 seconds. It seems that it is
> sufficient that a network shared has been mounted
> before at all. Unmounting it will not help.
> Also, just accessing network shares (i.e. without
> associating them to a drive letter) does not trigger
> the unfortunate behavior.
> Once the effect is triggered, I will either have to
> reboot or to re-connect to the network - it is just
> to slow to work with.
>
> * The delay will not occur for further accesses if
> the follow within a small window of time (10 secs?).
>
> Of course, I tune my settings for speed such that the
> usual suspects (virus scanner, overlays on NW drives)
> are not likely to blame.
>
> From what I have seen of the TSVNCache access code,
> there are possible explanations for both effects:
>
> * It seems that there is a sequential Explorer->TSVNCache
> round-trip for every item in the explorer. If that
> observation is correct, unfortunate scheduling could
> cost one or even two time-slices (~30 ms) per item.
>
> -> maybe, we could send the state for *all* nodes in
> the same folder as answer, if available. The explorer
> plugin could then cache the info for a few msecs.
Explorer doesn't ask for the overlays in an ordered fashion. And not
even all from the same folder - depending on whether the tree view is
shown or not and also depending on OS, it also asks for the parent
folder or even the folder above that.
> * There is a 10 second time-out for TSVNCache to answer
> a request. So, the Explorer might frequently ask for
> unavailable drives / folders, for some reason.
>
> -> maybe, we can come up with an asynchronous protocol
> between TSVNCache and the Explorer. There must
> already be something like that in place for
> nested folder status updates. So, there would be
> no reason to wait for data that has not already been
> fetched by TSVNCache.
The problem is not so much the status of items which are not yet in the
cache. It's that if a status request from the explorer should be
answered but the cache itself is locked because it is currently fetching
the status of an item (could be the same or another), the cache can't
answer that request (it's locked) until the call to svn_client_status()
returns.
There's a two second timeout: it the cache can't get a lock to answer an
explorer request within two seconds, it returns 'unversioned' to not
block that request for too long.
> Now, I tested Wednesday's nightly (r16319) and this
> is what I found:
>
> * Speed is back to normal as it was during 1.6.0
> development, maybe slightly better than 1.5.x.
> The above mentioned effects are still there.
>
> * There seems to be a serious flaw that should not
> be released with 1.6.2. No overlays are shown
> within the top-level folder of a large WC. Everything
> works fine for the top-level folder (e.g. /trunk)
> itself and for smaller projects (<=10k files)
> as well. F5, reboot, un-install TSVN etc. do not
> fix it.
But this (I think) was also the case in earlier versions. If you have so
many files in one folder, explorer stops asking for status after a
certain time.
> What do you think? Shall we put a thorough revision of
> TSVNCache on the 1.7 TODO-list?
Be my guest!
But you might have noticed that even small changes can have a big impact.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=2113455
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-05-08 15:31:12 CEST