While I understand your complaints, unless your product is a network layer component(s) I can bet my ass (and I'm not gay! :P) that copying memory around won't be a performance issue. WRT memory allocation - well, this will most certainly run faster than native code because: a) you don't track memory and don't have to delete it (and memory allocation is really really fast), and b) unless you're using a custom memory allocator, native code itself won't do you any good
Other than that, C++ is the way, the truth and the life ;) Re your 2 problems: 1) is not an issue - build your own Buffer class, and a Buffer pool or whatever and don't call methods you know will allocate memory 2) WFMO on varying handles is a common pattern in server apps and you don't have to worry about the overhead, because if carefully designed, your software will very rarely need to re-build the handles array Cheers, Stoyan On 10/29/06, Itay Zandbank <[EMAIL PROTECTED]> wrote:
Hi. For the first time since I started working with .NET, I need to write some TCP/IP code. While I only need to connect to a server socket, send one handshake packet and wait for incoming data, I started having very dim thoughts about high-performance communication servers in .NET . First there's the problem of packing binary data into a byte[] ready to be sent to the network. I want to take a 32 bit integer and put it in offest 50 of a byte[] array (which is my outgoing message). Naturally, I can do this: BitConvert.GetBytes(IPAddress.HostToNetworkOrder(myInt)).CopyTo(msg, 50); What this does (unless I'm missing something) is allocate a 4-byte array, put the number in it, copy the 4 bytes to my outgoing message buffer and, when it's time for garbage collection, free the 4-byte array. This isn't the most efficient way to accomplish this, and I'm being polite. If BitConvert offered a GetBytes(int, byte[], offset) method, it could have worked a lot faster (and I do mean A LOT). This is the smaller problem of the two. I can write an unsafe version of BitConvert that will spare the extra memory allocation and copy. The bigger problem I encountered was waiting for incoming socket events. My application waits for two kinds of events - socket events and another WaitHandle that is set when there's some other work to do. To make everything work, I call BeginReceive/BeginConnect/BeginSomething on my socket, and in the main loop I WaitHandle.WaitAny(...) on my handles (event and last socket operation handle). This works, but generates memory allocations inside BeginReceive. I also need to allocate my WaitHandle[] array every time, because sometimes I wait for 2 handles and sometimes just for 1. I could allocate two arrays in advance and use the appropriate one, but it will turn ugly if the number of handles I wait on varies... While the performance impact on my application is negligible, this sort of overhead can be a killer for a high-performance server application. Do server developers need to resort to Windows API to use IOCPs and control when memory is allocated using the unmanaged heap (basically saying C++ is the way to go and not C#)? Thanks, Itay.
=================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
