Slow Performance when making IPC calls using named pipes
alberto-carp opened this issue · 6 comments
Hi,
I use a custom client application which uses the framework https://github.com/UiPath/coreipc to send multiple messages to a server ( client - server over IPC). I want o be able to attach to the client application using the NetcoreDbg.
Since I'm doing a lot of IPC calls I noticed some performance discrepancies between NetcoreDbg and visual studio proprietary debugger ( like 30x)
I tested in isolation using the client/server architecture from the tests from https://github.com/UiPath/coreipc and the perf was as follow:
~120 IPC calls per seconds when using NetcoreDbg;
~4000 IPC calls per sec when using visual studio debugger or no debugger attached to the client.
Are there any knowns issues with IPC calls when attached to a given application, or do you know some reasons why it performs so poorly.
Also I tested only with that framework, I did not tested with others frameworks or some dummy named pipes to do IPC calls.
The issue can be easily reproduced, by firstly running the IpcSample.ConsoleServer from the framework and then running the IpcSample.ConsoleClient ( and attach to the process before the test execution , by inserting a Console.ReadKey).
I'm using Windows x64 and latest build.
Which protocol do you use? Command line interface or from Visual Studio/VS Code?
I tried both. The IpcSample.ConsoleClient tests were run by using the CLI interface ( attach while tests were running from CLI), but I noticed the issue in my application ( which is using the VSCode interpreter)
This slowdown behavior is unexpected. Can you try to profile your application process with/without attached netcoredbg to see what's going on (with some analog to perf/gprof on windows)?
Hi. Yes I've used the Visual Studio default profiler tool. From what I've seen it seems that when attached with NetCoreDbg we are spending a lot of times in NotifyOfCrossThreadDependencySlow and also waiting in the Semaphore (alomost 50% - see image).
.
This does not seems to happen when attached with VSDebugger or not attached at all. I attached all the profiler sessions (netcoredbg attached, not attached, vsdebugger attached)
I see the point, looks like MS debugger setup ICorDebugProcess3::SetEnableCustomNotification() during eval execution only, but we setup it for all debug session, that mean during debug session with our debugger debuggee process are stopped and called ICorDebugManagedCallback3::CustomNotification() even during normal code execution.
I will revise NotifyOfCrossThreadDependency related logic in netcoredbg.
This should be fixed in latest release. Feel free to reopen if you see any more related issues.