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

Re: Use COM for shell extension / TSVNCache communication

From: Ivan Zhakov <chemodax_at_gmail.com>
Date: Fri, 25 Mar 2016 09:50:31 +0300

On 25 March 2016 at 09:38, Stefan Küng <tortoisesvn_at_gmail.com> wrote:
> On 24.03.2016 19:24, Ivan Zhakov wrote:
>> On 24 March 2016 at 20:48, Stefan Küng <tortoisesvn_at_gmail.com> wrote:
>>> On 24.03.2016 07:42, Ivan Zhakov wrote:
>>>> Hi,
>>>>
>>>> Currently Tortoise shell extension uses named pipes for communicating
>>>> with TSVNCache.exe. I'm considering to change this to use COM for
>>>> inter-process communication. This should improve performance and
>>>> concurrency.
>>>
>>> Are you sure that COM is faster than a simple pipe? From my experience I
>>> found COM to be slower. Of course my last attempts at this were five
>>> years ago so things might have changed...
>>>
>> COM performance didn't change significantly in the past five years.
>> But I expect COM to be faster for several reasons:
>> 1. COM uses LRPC for communication which extremely fast. It uses
>> shared memory and NDR/NDR64 for marshaling data.
>> 2. Free-threaded COM server uses thread-pool to execute interface methods.
>> 3. There is no ERROR_PIPE_BUSY race condition between client connected
>> to the pipe and server created new pipe.
>> 4. The client may call interface methods concurrently from different
>> threads without using mutex.
>>
>> There some overhead of using COM, but the transport itself should be
>> faster. Btw how did you measure performance? Did you use typelibrary
>> based marshaller or registered separate proxy dll? What threading
>> model did you use for COM server in your tests?
>
> The measuring was done using a long loop of communication calls and
> measuring the time it took. All done with apartment threading for COM.
Apartment thread COM server could be slower, since all RPC calls
should be translated to main thread. I'm not sure how this currently
implemented, but usually it's done via message-loop.

> While the COM performance was only slightly slower than the pipes, it
> was noticeable in that situation. I think the reason was that the data
> sent/received was very small. Because when we increased the data size
> the difference between COM and pipes got smaller and smaller.
>
> So I guess for the cache, COM could be faster. But I'm not sure.
> Do you think it's worth the effort?
>
I'm not sure whether it's worth the effort or not. I thought that
COM/LRPC should be faster than named pipes. Another problem I wanted
to improve is the situation that currently TortoiseSVN shell extension
makes shell effectively two-threaded: one main thread for UI while
all Explorer worker threads are serialized (blocked) due TortoiseSVN
mutex.

-- 
Ivan Zhakov
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=3167179
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2016-03-25 07:53:47 CET

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.