Re: Use COM for shell extension / TSVNCache communication

On 25 March 2016 at 10:06, Stefan Küng <tortoisesvn_at_gmail.com> wrote:
> 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.
I didn't want to reduce the reads. I wanted to actually use them,
instead of waiting for CRemoteCacheLink mutex.

> But if it's not too much work, you could try it out and then check if
> it's faster/better.
>
I did some simple performance tests and you are right: named pipes are
slightly faster (10-15%) than COM via LRPC. Another interesting
findings: using overlapped I/O also takes some significant proportion
of time.

Very rough results of performing 20k calls with 50 bytes arguments:
- Named pipes using overlapped I/O on the client: 0.064 ms for one call.
- Named pipe without overalpped I/O on the client: 0.045 ms for one call.
- COM with MTA server and MTA client: 0.07 ms for one call
- COM with MTA server and STA client: 0.115 ms for one call.
- COM with STA server and STA client: 0.152 ms for one call.

It's not too much work to start using COM for TSVNCache, but given the
numbers above we may expect more overheads for one call. I'm not sure
that improved threads/cores utilization compensate this.

-- 
Ivan Zhakov
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=3167185
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].