John Blumenauer's Blog

.NET Development and Community Nuggets
posts - 46, comments - 13, trackbacks - 0

My Links

News

Twitter












Article Categories

Archives

Post Categories

Development Tools

User Groups

Interop with .NET Framework 3.5 Pipes?

Recently, I was tasked with doing some serious re-factoring on an application where the UI was WinForms and the back end was native C++.  The intent was to re-factor the native code into C# because of the performance hit we were taking with the interop between the managed/unmanaged code (this is a extremely processor intensive application) and because the native code back end was beginning to cause some serious limitations regarding feature extensibility.  Previously, the interop was via callbacks.  However, with the redesign, callbacks would no longer be appropriate.  This is where the Pipes concept comes in.  After a bit of experimenting, I determined that using a Pipe Server to send data from the unmanaged code to the managed code provided excellent performance.  Thus far, the performance of the application has dramatically improved from the original design.  Has anyone else tried this?  And if so, have you seen any negative effects? 

Print | posted on Wednesday, January 28, 2009 9:38 PM |

Feedback

Gravatar

# re: Interop with .NET Framework 3.5 Pipes?

Pipes or Sockets should work roughly equally as well on the same computer; the specific implementation and the communication protocol details will make the difference in high performance app. I have done both.

In addition, I have also placed data in a shared data segment in a DLL that both the managed and unmanaged code can load/attach to. You still have to Marshal back and forth managed code/unmanaged code, but if you define a "block of bytes" you can transfer that super-quickly. This is exactly what we have done, with the byte arrangement stored in a "database" (or configuration file, etc). Don't forget about thread synchronization on the data access, in this case.
1/29/2009 6:11 AM | Bill
Gravatar

# re: Interop with .NET Framework 3.5 Pipes?

The shared data segment DLL can also be implemented in a memory-mapped file.

Almost forgot: We did not use pipes in production, we went with sockets (even though it was the same computer running both programs).

Negative effects?

The usual complexities with sharing data between applications.

Some of the research work is up on codeplex: http://www.codeplex.com/ipclibrary/

But nothing with Pipes or Sockets since that is accomplished using existing .Net framework 2.0 class library.
1/29/2009 6:17 AM | Bill
Gravatar

# re: Interop with .NET Framework 3.5 Pipes?

Bill, thanks for your feedback. The memory-mapping was an alternative that I considered, but given the short time frame, pipes seemed like a faster implementation. You're right, regardless of pipes, sockets, or memory-mapping, the performance is largely dependent on the actual implementation. I'll definitely take a look at your research on codeplex. I know sockets have been in the .NET Framework for awhile, but isn't the pipes classes new in .NET 3.5? Again, thanks for the feedback.
1/31/2009 11:38 AM | John Blumenauer
Post A Comment
Title:
Name:
Email:
Website:
Comment:
Verification:
 
 

Powered by: