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