Hi All,
There has been much discussion about IPC-related performance issues with my
proposed caching scheme. This has ranged from confident but
unsubstantiated remarks such as "named pipes are slow", to a variety of
other approaches, some of which would seem to require duplicating much of
the cache process within the shell extension, to avoid evil IPC overheard.
As is fairly standard for this type of discussion, none of us had any
measured numbers to throw into the discussion.
So I've performed the following test:
Created an application which borrows the named-pipe client code from the
shell extension. This application makes 100000 requests for the status of
the same file from the TSVNCache process. Because TSVNCache has a special
'last file' cache, with a lifetime of 1 second, almost all these requests
are satisfied without going near the main cache.
On a fast machine (3G P4), 100000 status fetches takes about 3.5
seconds. (35usec per fetch). I think it unlikely that explorer would
ever need to fetch more than 100 files-worth of status in one go (on XP at
least, it only fetches status for those items which are visible in the
window). This would add about 3.5ms to the display time, if we put the
'last file' cache into the shell extension. It would be about 4-5 times
more if we left the 'last file' cache in the TSVNCache process. (For
everyone except Stefan and me, this is because Explorer often asks for the
status of a file 4 or 5 times in a row.)
Neither 3.5ms nor 35ms would be significant, I feel. To help people who
have machines which are strangely slow at named pipes, but who have large
high-res displays (hence lots of files) and fast graphics, we should
probably put the 'last-file' cache in the shell extension.
I would suggest that we could put everything else in the TSVNCache process,
thereby avoiding it having any kind of cache policy handling code.
One caveat is that I need to increase the size of the returned block of
data somewhat, because it's currently missing information which the column
provider needs. I don't expect this to make any significant change to the
performance.
Cheers,
Will
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Sun Jan 23 21:06:37 2005