Cook Computing

.NET Remoting can soak up a lot of CPU even when you have only a few hundred calls per second. To determine whether it would be worth working on a channel implementation to improve performance I tinkered around yesterday with an in-process channel which eliminated the cost of moving the call data cross-process. The baseline was a named pipe channel which was achieving around 3000 calls/sec on my dev machine (for a method taking an int and returning a string). The in-process channel, which had client and server running on different threads and synchronized by an event, improved on this but only up to 4000 calls/sec. So it doesn't seem worthwhile to spend a lot of time trying to better the performance of the named pipe channel when any implementation has to transfer the call data cross-process and inevitably achieve considerably less than 4000 calls/sec. This involves marshalling the transport headers and request stream to the server process, and headers and response stream back to the client process.

Scoble writes about how smart displays have failed. The scenario he describes could be pretty compelling:

What was a Smart Display? An LCD panel that would display images from a high-power server. Interesting idea, if the cost were, say, $300 each (instead of $1000). Imagine having a server in your closet with, say, a dozen panels, instead of a single Tablet PC. You could display pictures on one. Recipes on another. Have your son playing a video game on another. Your daughter doing homework on yet another. All hooked to a server via WiFi.

However the cost of the Smart Displays is not the fundamental problem with this scenario: you can only connect one Smart Display to a host machine running XP and, to make things worse, when that display is being used the screen attached to the host machine can't be used. Presumably there aren't any fundamental technical issues with this and it's just a matter of Microsoft wanting people to buy more XP licences. For the 4 person family to each use a Smart Display concurrently, they would need to buy 4 PC's and 4 Smart Displays instead of 1 PC and 4 Smart Displays.

It is often thought that to implement cross-process synchronization on a Windows OS you need to use a kernel object such as a mutex which involves a switch to kernel mode, and back to user mode, everytime the lock is acquired and released; in contrast to a critical section which does not incur the overhead of the mode switch if there is no contention for the lock but which can only be used within a process. But, in fact, it is quite possible implement a critical section-like object which works cross-process, the key to this being the use of shared memory. Jeffrey Richter describes just such an object in this article in MSDN Magazine January 1998. This COptex class also contains a configurable spin lock implementation for use on multi-processor systems.

On the project I'm working on at the moment the use of COptext makes a significant difference to CPU usage in certain scenarios.

I've removed support for comments from this blog. Thanks to everyone who added interesting comments in the past. The .NET Guy has explained the situation already, here and here.

Just after I'd discovered Renaud Paqauy's Microsoft.Win32.Security code, I came across Dana Epp blogging about the same.