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

Re: TSVNCache uses 100% processor time on quad-core pcs

From: Stefan Küng <tortoisesvn_at_gmail.com>
Date: Tue, 24 Feb 2009 19:50:50 +0100

Stefan.Fuhrmann_at_etas.com wrote:

> Actually, I'm quite happy when I see that sort of behavior:
> TSVNCache is running at a time when all data is still present
> in the Windows file cache. The point is that it should finish
> processing these changes soon after the svn operation finished.
> It works perfectly on my machines.
>
> <braindump>
> Things that we should have a look at:
>
> * Do we frequently process paths more than once?
> A bit of duplication would be o.k. but we should not
> try to fetch status info that is bound to be invalidated
> soon after.

Not really. After we process a path, we set a time for that path in
which that specific path is left alone and not crawled anymore. Only
when that time elapsed we crawl that path again.

> * Can we optimize the cache implementation?
> Maybe, a significant (>30%) of the runtime is spent
> outside the SVN libs.

There are not many places which we can optimize. Because we already
optimized a lot.

> * Could notifications be processed in low-prio threads?
> Requests from the Explorer would use normal prio or
> even higher prio (-> no Explorer lock). TSVNCache would
> then use only the spare cycles to update the status info.

We already use low prio threads. Lowering the thread prio more (Vista
has some special low-prio threads used mostly by the search indexer)
doesn't work reliably, because those threads are only executed when the
system is idle - which means the overlays are not updated unless you
leave your computer for a few minutes alone. Such overlays are almost
always wrong and therefore completely useless.

> Despite all of that, I would like to see some way to suspend
> and resume the cache: As soon as the file cache is no longer
> sufficient, the status update eats away most of the I/O cycles.
> It can happen for compiler runs, for instance.
>
> So far, I see two options to address this issue:
>
> * Add a simple CL interface to suspend and resume the cache.
> Build scripts could easily use that feature.
>
> * Monitor disk I/O load (separate for each disk) and
> accelerate / throttle down the respective monitor threads.
> This is pretty hard to do but should yield the best
> perceived performance.

this might work. But not easy to do.

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=1221932
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].

Received on 2009-02-24 19:51:14 CET

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