码迷,mamicode.com
首页 > Web开发 > 详细

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

时间:2015-06-18 21:31:33      阅读:140      评论:0      收藏:0      [点我收藏+]

标签:

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.

 

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

标签:

原文地址:http://www.cnblogs.com/networkcomms/p/4586765.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!