Matthew Ratzloff wrote:
> I've run some more extensive testing to figure out the problem. Here
> are the results.
>
> 1. I disabled ALL non-Microsoft shell extensions. There were only
> three: iTunes, Anapod Explorer, and VDMSound. Only the first two are in
> common between this machine and my work machine (otherwise, my home
> machine and work machines are fairly different).
>
> I checked out a repository and watched the CPU usage. At first,
> TortoiseProc.exe was running at about 50-70%, with occasional spikes
> from TSVNCache.exe. About halfway through, explorer.exe (the main
> process, controlling the Start Menu and desktop) began to climb until it
> was about 90%. The download also slowed down considerably. I killed
> the explorer.exe process, the checkout sped up, and everything worked
> fine. When I opened the folder with the checked-out files, it opened
> immediately. However, it only did this because I killed the
> explorer.exe process.
>
> 2. Next, I also disabled my real-time virus scanner. I checked out the
> repository. The results were identical. This time, however, I did not
> kill the explorer.exe process prior to completion. It completed, and I
> clicked on the folder to see the files. No files displayed, and
> explorer.exe stability overall began to decline and usage increase. At
> this point, I suspected TSVNCache.exe had some role, so I killed it. It
> didn't do anything. I killed explorer.exe. The folder and files
> immediately displayed fine. Not entirely convinced about TSVNCache.exe.
>
> 3. I opened a folder view window and ran "svn co" from the command line.
> Briefly, TSVNCache.exe jumped to the top of the CPU usage and then
> explorer.exe jumped to 80-90% usage. I killed them all and began again.
>
> 4. This time I closed all folder view windows and killed TSVNCache.exe
> prior to doing anything (call it a pre-emptive strike). I ran "svn co"
> from the command line. No explorer.exe CPU jump. I opened a folder
> view window after the checkout completed. No explorer.exe CPU jump. I
> click in the folder itself and everything is fine.
>
> And the clincher:
>
> 5. I opened a folder view window and killed TSVNCache.exe. I then used
> TortoiseSVN to check out a repository as I watched the processes and CPU
> usage. The checkout completed normally, and explorer.exe never spiked.
> I then clicked on the folder. TSVNCache.exe started up, but still
> explorer.exe never spiked. The icons had no overlays. I refreshed the
> folder contents and the overlays appeared. Even then, explorer.exe CPU
> usage didn't spike.
>
> So the problem is TSVNCache.exe. At a certain point during a checkout
> or update, TSVNCache.exe briefly influences explorer.exe in some way
> that makes it consume as many cycles as possible. If it's not running,
> no spike occurs. I can reproduce this 100% of the time. I also want to
> stress that explorer.exe simply does not do this at all unless I run an
> update or checkout with TortoiseSVN. I can literally not use the
> interface for weeks, and the one time I do it immediately causes a problem.
Thanks a lot for the expensive testing.
There's a problem though: I've now tried over three days several hours
to reproduce this. While I could make the explorer process to use a lot
of CPU, I never got it to use 100% CPU. Sure, sometimes during a
checkout it would use a lot of CPU, but after the checkout was finished
it was ok again.
I've used different repositories to check out from. I even used my
locally mirrored TSVN repository and checked out from its root, just to
get a *huge* working copy. But even then, the explorer process would not
get locked at 100% CPU.
> Finally, even though I'm the only reporting it, that doesn't really mean
> anything. Some others might be experiencing this, but it's entirely
> possible that I'm the only one who a) didn't immediately uninstall it
> the first couple of times it occurred, and b) took the time to report it
> as a bug.
In my experience, there are so many people out there using TSVN that if
such a problem really was wide spread, I would hear about it at least
twice a day.
> Thanks for looking into this. I appreciate everyone's hard work.
The only thing I can think of is that the cache (TSVNCache) process
sends update notifications to the shell to tell it about status changes.
The shell uses those notifications then to update the overlay icons.
What I've seen happen sometimes is that the shell doesn't like to be
"pushed". If too many notifications are sent to the shell process, then
the shell can really lock up. But I only got this to happen if I write a
little test tool which sends such notifications at full speed in a
while-loop, and only if it sends more than about a hundred of them.
Maybe you have a much faster computer than I have? Because during
checkouts/updates/... the cache will send such notifications for many
files (during a checkout for every file), but not fast enough that the
shell would take this personally :) At least on my computer.
Anyway: I've put a Sleep(0) call in the Cache function where the shell
notifications are sent. That will prevent the cache from sending too
many notifications too fast.
Can you try a nightly build and see if the problem is still there? Or at
least a little bit better?
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Sat Feb 3 17:31:27 2007