Flanakin Michael C Ctr HQ OSSG/OMR wrote:
> I know that there have been issues with this in the past, but I never
> noticed a resolution or game plan for fixing the problem. I'm using TSvn
To have a plan, we first would need an idea on even *how* to fix/improve
> 1.2.2 on XP Pro and have been working with two different explorer
> windows open. I noticed my system running extremely slow while moving
> files around and developing my app, so I checked the running processes.
> TSvnCache.exe is eating 27-48% of my CPU power (it mostly hovers around
> 35%). I thought this might be because of the two windows, so I closed
> them. It popped down to 10% momentarily, but then jumped back up to the
> 30+ range. From what I've noticed, it only goes lower when something
> else is eating up more processor power.
If you have really big working copies, the CPU consumption of the cache
is around 30% until *all* your working copy files have been scanned at
least once and are in the cache. This can take some time (e.g. for the
checked out trunk folder of TSVN it will take around 3 minutes - now
calculate that up for your working copy).
But after that, the cache process should be almost idle. Of course, only
until you start modifying files in your working copy. Then the cache
crawls that folder again (but that won't take much time - you will only
see a short peak in the CPU usage of the cache).
> I read somewhere that the process was supposed to run with an "idle"
> priority, so I checked that and saw that it was set to "normal". I
> changed it to "low", which is why I'm guessing it bumps down when other
> apps are using the processor.
Depends on which thread you're looking at. Most threads in the cache
*are* set to idle, but others (like the one listening for explorer
status requests and the file system watcher) simply can't be made idle.
> I can deal with it using 35% of my processor when other apps aren't; but
> I wanted to find out if this is the intended usage. I feel like I'm
> running slower during some operations (i.e. compiling and replacing
> files); but that may just be me.
> Oh, and I'm using a 2 GHz machine with 1 GB RAM, if that helps any.
I just wrote a little stress test tool for the cache (specifically the
file system watcher). And yes, if I modify 3000 files in about 5 seconds
then the cache will use up to 70% CPU for about 5 minutes. But that's
not only because of the cache but also because then all files have their
last-write-time modified and Subversion then has to do a full binary
compare of the working copy files with their base to get the status.
If you have a build system which touches your sourcefiles, then I'm
afraid the cache really can slow your system down a little. You should
then do a 'cleanup' on your working copies more often to reset the
last-write-times of the working base.
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Fri Sep 2 20:47:45 2005