Question: Overhead involved using Asynchronous network receives with ArraySegment<byte[]>?

Question

I'm developing a socket server that needs high performance... I'm currently pooling byte arrays alone for receiving data, but I implementing a new buffer system which involves using arraysegments.

Is there any overhead involved with using ArraySegments containing a byte array? If so, how much?

The model I'm trying to implement goes like...

Server receives amount of bytes, If it got all the data and processed it, then

- It releases the current buffers held and gets a new one

If it didn't get all the data, then

- If theres no room in the current buffer, so create a new stored buffer.
- If there is room, adjust the offset.

Answer 1

Well, ArraySegment is a struct, so it's created on the stack, not the heap.  As long as you're not typing in something that will get boxed you should be about as fast as you can get with that approach (bytes and structs are both on the stack).

There is always overhead in allocating resources, but the stack is by all means the fastest.  Set up a loop with ArraySegments being built and time 10,000 iterations to get an idea.  It's more likely that you'll spend more cycles testing to see if the data is "complete" than you will in creating a struct. 

Hope this helps.

Cheers,

-jc

---

Me, coding and stuff: Mr. James

Answer 2

Thank you for answering my question :)
Also, thanks for reminding about wasting cycles in that part of code! (Also on how that is probably the most performacne critical part of my net code).

Hmmm do you have any suggestions to optimize my network receiving? (cycles wise that is). Couldn't really think of another way of doing it.

Answer 3

I would likely just go with a big enough buffer that it doesn't hurt you otherwise (how important is near-realtime?) and process everything when your buffer is filled.

Push the data from the full buffer (perhaps to a different thread) for the processing and let it figure out 'offline' if a message is 'complete' or if it needs to keep a partial message around for the next buffer dump.

As far as implementation goes, I'll have to concede here that I'm outside my area of expertise, so these are just educated guesses.  Without knowing your exact purpose and design/performance goals, it's hard to comment further, but I do hope this has helped.

Cheers,

-jc

---

Me, coding and stuff: Mr. James