官方论坛对Networkcomms v3性能的讨论，先记录一下

www.networkcomms.net官方论坛对Networkcomms v3性能的讨论，先记录一下

I replaced the StreamTool.Write implementation with a simple synchronous version:

 public static double Write(Stream inputStream, long inputStart, long inputLength, Stream destinationStream, int writeBufferSize, double timeoutMSPerKBWrite, int minTimeoutMS)
        {
            if (inputStream == null) throw new ArgumentNullException("source");
            if (destinationStream == null) throw new ArgumentNullException("destination");
 
            //Make sure we start in the right place
            inputStream.Seek(inputStart, SeekOrigin.Begin);
 
            int bytesRemaining = (int)inputLength;
 
            int bufSize = Math.Min((int)inputLength, writeBufferSize);
            byte[] buf = new byte[bufSize];
 
            while (bytesRemaining > 0)
            {
                int count;
                if (bytesRemaining < buf.Length)
                    count = (int)bytesRemaining;
                else
                    count = buf.Length;
 
                inputStream.Read(buf, 0, count);
                destinationStream.Write(buf, 0, count);
 
                bytesRemaining -= count;
            }
 
            return 0;
        }
 

Now the performance is fine!
First I thought the allocation of the various buffers and objects in your implmenentation is the reason, but now I suppose it’s due to the overhead of thread/context switching from the asynchronous stream begin/end methods.
Tested it with a slightly modified version of your ExamplesConsole AdvandedSend example which runs now five times faster.
Send calls per second increased from 5000 to 25000 on localhost and CPU load dropped to one third.