Re: Use COM for shell extension / TSVNCache communication

On 25.03.2016 07:50, Ivan Zhakov wrote:
> 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.

The shell uses multiple threads on its own for this. At least since
Win7. It uses a background thread to get the overlay information. So
using COM won't reduce the threads.

But if it's not too much work, you could try it out and then check if
it's faster/better.

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