Re: [TSVN] Yet more shell optimisation

Will Dean wrote:

> I'm still looking at shell extension optimisation, largely still running
> very aggressive tests on IsMemberOf.
>
> Now that all the big things are done, it's still apparent that the
> PathIsDirectory call in IsMemberOf is expensive. (According to DPP,
> about 20% of the time in a test where I read the (cached) status of a
> pair of files 20000 times each).

This is true for versioned folders. It will increase the time (a tiny
little bit) for non versioned folders though. But I think it's still
worth it.

Maybe you should expand your testsuite to include calling the
IsMemberOf() for non-versioned files in a non-versioned folder to get a
more detailed view.

But then, it's always possible to exclude non-versioned folders in the
settings dialog, so this isn't really a big issue.

> As an experiment, I made a separate member in SVNFolderStatus called
> 'GetCachedItem', which took *only* a path argument. This function just
> contains the m_cache.find() code from GetFullStatus, and it returns a
> status pointer if it finds the entry in the cache, or NULL if it doesn't.
>
> I call this in IsMemberOf *before* the PathIsDirectory - if it returns
> null, then I proceed with the usual stuff. If it finds a cache hit,
> then I just use that value, and skip all the usual content of IsMemberOf.
>
> So in role and position it's just like the single file 'mini-cache'
> test, but instead it's searching the full cache.
>
> Before running the stress test, I pre-loaded the cache by getting the
> status on a folder - the cache had 80 items in, which is probably not
> unrepresentative.

Implemented that in revision 1895.

> This turns out to be *enormously* faster. My test run reduced from
> about 1100ms to about 180ms, merely through avoiding 40000 calls to
> PathIsDirectory.
> (Not sure how this squares with DPP's 20%, but it's definitely removing
> PathIsDirectory which makes the difference - putting a dummy call to it
> in restored the run time to around 1100ms.)
>
> It feels that this would be worthwhile - even if the cache was a lot
> bigger, I don't think its lookup time would rise significantly -
> std::map lookups are O(log(n)) anyway.

Well, on my computer it doesn't help very much. An improvement of about
30%, but I guess that's because I have a very slow laptop to work on ;)

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org