序列化
二进制序列化是.NET的另一个领域。BinaryFormatter最初并不是.NET Core中的一个组件，但是它包含在.NET Core 2.0中。该组件在性能方面有比较巧妙的修复。例如，PR dotnet / corefx＃17949是一种单行修复，可以增加允许增长的最大大小的特定数组，但是这一变化可能对吞吐量产生重大影响，通过O（N）算法比以前的O（N ^ 2）算法要话费更长的操作时间。以下代码示例，明显的展示了这一点：
using System;using System.Collections.Generic;using System.Diagnostics;using System.IO;using System.Runtime.Serialization.Formatters.Binary;class Test
在.NET 4.7中，代码输出如下结果：
76.677144
而在.NET Core 2.0中，会输出如下结果：
6.4044694
在这种情况下显示出了12倍的吞吐量提高。换句话说，它能够更有效地处理巨大的序列化输入。
文字处理
.NET应用程序中另一种很常见的计算形式就是处理文本，文字处理在堆栈的各个层次上都有大量的改进。
对于正则表达式，通常用于验证和解析输入文本中的数据。以下是使用Regex.IsMatch重复匹配电话号码的示例：
using System;using System.Diagnostics;using System.Text.RegularExpressions;public class Test
在个人计算机上，.NET 4.7会得到的如下结果：
Elapsed=00:00:05.4367262 Gen0=820 Gen1=0 Gen2=0
而使用.NET Core 2.0会得到如下结果：
Elapsed=00:00:04.0231373 Gen0=248
由于PR dotnet / corefx＃231的变化很小，这些修改有助于缓存一部分数据，因此吞吐量提高了25％，分配/垃圾收集减少了70％。
文本处理的另一个例子是各种形式的编码和解码，例如通过WebUtility.UrlDecode进行URL解码。在这种解码方法中，通常情况下输入不需要任何解码，但是如果输入经过了解码器，则输入仍然可以通过。感谢来自hughbe的 PR dotnet / corefx＃7671，这种情况已经被优化了。例如下面这段程序：
using System;using System.Diagnostics;using System.Net;public class Test
在.NET 4.7中，会得到以下输出：
Elapsed=00:00:01.6742583 Gen0=648
而在.NET Core 2.0中，输出如下：
Elapsed=00:00:01.2255288 Gen0=133
其他形式的编码和解码也得到了改进。例如，dotnet / coreclr＃10124优化了使用一些内置Encoding -derived类型的循环。例如下面的示例：
using System;using System.Diagnostics;using System.Linq;using System.Text;public class Test
在.NET 4.7中得到以下输出，如：
00：00：02.4028829
而.NET Core 2.0等到如下输出：
00：00：01.6133550
这些改进也适用于字符串和其它类型之间转换，例如.NET中生成Parse和ToString方法。使用枚举来表示各种状态是相当普遍的，例如使用Enum.Parse将字符串解析为相应的枚举。PR dotnet / coreclr＃2933改善了这一点。请查看以下的代码：
using System;using System.Diagnostics;public class Test
在.NET 4.7中，会得到的以下结果：
Elapsed=00:00:00.9529354 Gen0=293
在.NET Core 2.0上，会得到以下结果：
Elapsed=00:00:00.6448327 Gen0=11
不但吞吐量提高了约33％，而且分配和相关垃圾收集也减少了约25倍。
当然，在.NET应用程序中需要进行大量的自定义文本处理，除了使用像Regex / Encoding这样的内置类型和Parse和ToString这样的内置操作之外，文本操作通常都是直接构建在字符串之上，并且大量的改进已经引入到了操作on String之上。
例如，String.IndexOf很擅长于查找字符串中的字符。IndexOf在bnetyersmyth的dotnet / coreclr＃5327中得到改进，他们为String实现了一系列的性能改进。正如下面的例子：
using System;using System.Diagnostics;public class Test
在.NET 4.7上，会得到如下结果：
00：00：05.9718129
而在.NET Core 2.0中，会得到如下结果：
00：00：03.1283763
吞吐量提高约2倍。
下面是比较字符串部分。这是一个使用String.StartsWith和序数比较的例子：
using System;using System.Diagnostics;using System.Linq;public class Test
在.NET 4.7上会得到如下结果：
00：00：01.3097317
.NET Core 2.0会得到如下结果：
00：00：00.6239002
对String的改进，也让我们看到对于其它方面进行更多改进的可能性，这是非常有趣的。
文件系统
到目前为止，本文一直专注于内存中操纵数据的各种改进。但是.NET Core的许多更改都是关于I / O的。
下面从文件开始介绍。这是一个从文件中异步读取所有数据并将其写入另一个文件的示例：
using System;using System.Diagnostics;using System.IO;using System.Threading.Tasks;class Test
FileStream中的开销也在进一步减少，例如DOTNET / corefx＃11569增加了一个专门的CopyToAsync实现，dotnet/ corefx＃2929也改进了异步写入的处理，.NET 4.7会得到如下结果：
Elapsed=00:00:09.4070345 Gen0=14 Gen1=7 Gen2=1
.NET Core 2.0会得到如下结果：
Elapsed=00:00:06.4286604 Gen0=4 Gen1=1 Gen2=1
网络
网络是值得关注的部分，这部分也将取得很大的改进。目前正在付出很大的努力来优化和调整低等级的网络堆栈，以便高效地构建更高级别的组件。
这种改变带来的一个很大的影响是PR dotnet / corefx＃15141。SocketAsyncEventArgs是Socket上大量异步操作的核心，它支持同步完成模型，因此异步操作实际完成了同步操作，这样避免了异步操作的分配消耗。但是，.NET 4.7中的同步操作运算是失败的， PR修复了上述的实现问题，允许在socket上进行所有异步操作的同步完成。这样的提升在以下代码中变现的非常明显：
using System;using System.Diagnostics;using System.Net;using System.Net.Sockets;using System.Threading;using System.Threading.Tasks;class Test
该程序创建两个连接的socket，然后向socket写入1000次，并且在案例中使用异步方法接收，但绝大多数操作将同步完成。在.NET 4.7中会得到如下结果：
Elapsed=00:00:20.5272910 Gen0=42 Gen1=2 Gen2=0
在.NET Core 2.0中，大多数操作能够同步完成，得到如下结果：
Elapsed=00:00:05.6197060 Gen0=0 Gen1=0 Gen2=0
不仅仅是直接使用socket来实现组件的这种改进，而且还通过更高级别的组件来间接使用socket，其他PR的结果是更高级别组件（如NetworkStream）的额外性能提升。例如，PR dotnet / corefx＃16502在SocketAsyncEventArgs上重新实现了基于Socket的SendAsync和ReceiveAsync操作，并且允许它们在NetworkStream中使用。Read / WriteAsync和PR dotnet / corefx＃12664添加了一个专门的CopyToAsync重写，以便更有效地从NetworkStream读取数据并将其复制到其他流中。这些变化对NetworkStream吞吐量和分配有非常大的影响。看看下面这个例子：
using System;using System.Diagnostics;using System.IO;using System.Net;using System.Net.Sockets;using System.Threading;using System.Threading.Tasks;class Test
与之前的Socket一样，下面我们创建两个连接的socket，然后把它们包含在NetworkStream中。在其中一个流中，我们将1K数据写入一百万次，而另一个流则通过CopyToAsync操作读出所有数据。在.NET 4.7中，会得到如下输出：
Elapsed = 00：00：24.7827947 Gen0 = 220 Gen1 = 3 Gen2 = 0
而在.NET Core 2.0中，时间减少了5倍，垃圾回收有效地减少到零：
Elapsed=00:00:05.6456073 Gen0=74 Gen1=0 Gen2=0
其它网络相关组件也将得到进一步优化。例如SslStream通常将围绕在NetworkStream中，以便向连接中添加SSL。下面的示例将看到这种影响，这个示例将在NetworkStream之上添加SslStream的用法：
using System;using System.Diagnostics;using System.Threading;class Test
在.NET 4.7中，会得到如下结果：
Elapsed=00:00:21.1171962 Gen0=470 Gen1=3 Gen2=1
.NET Core 2.0包含了诸如dotnet / corefx＃12935和dotnet / corefx＃13274等PR的改进，这两者都将大大减少了使用SslStream所涉及的分配。在.NET Core 2.0上运行相同的代码时，会得到如下结果：
Elapsed=00:00:05.6456073 Gen0=74 Gen1=0 Gen2=0
85％的垃圾收集已被删除！
并发
对于并发和并行性相关的原始化和基础部分，也得到了许多改进。
这里的一个关键点是ThreadPool，它是执行许多.NET应用程序的核心。例如，PR dotnet / coreclr＃3157减少了QueueUserWorkItem中涉及的某些对象的大小，PR dotnet / coreclr＃9234使用了ConcurrentQueue <T>重写来替换ThreadPool的全局队列，其中会用到较少的同步和分配。从以下的示例中，会看到最终结果：
using System;using System.Diagnostics;using System.Threading;class Test
在.NET 4.7中，会等到如下结果：
Elapsed=00:00:03.6263995 Gen0=225 Gen1=51 Gen2=16
而在.NET Core 2.0中，会得到如下结果：
Elapsed=00:00:02.1797508 Gen0=153 Gen1=0 Gen2=0
这是一个巨大的吞吐量的改善，并且这样一个核心组件的垃圾量也将大幅减少。
同步原语也在.NET Core中得到提升。例如，低级并发代码通常使用SpinLock来尝试避免分配锁定对象或最小化竞争锁所花费的时间。PR dotnet / coreclr＃6952改进了失败的快速路径，以下测试会得到显而易见的结果：
using System;using System.Diagnostics;using System.Threading;class Test
在.NET 4.7中，会得到如下结果：
00:00:02.3276463
而在.NET Core 2.0中，会得到如下结果：
00：00：00.3915327
吞吐量的这种差异可能会对运行这种锁的热路径产生很大的影响。
这只是众多例子中的一个。另一个例子围绕着Lazy<T>，它被PR dotnet / coreclr＃8963用manofstick重写，以便提高访问初始化过的Lazy <T>的效率。这样的提升效果从下面的示例中清晰可见：
using System;using System.Diagnostics;class Test
在.NET 4.7中，会得到的结果如下：
00：00：02.6769712
而在.NET Core 2.0中，会得到的结果如下：
00：00：00.5278348
吞吐量增加约5倍。
下一步是什么
本文只涉及了部分.NET Core的性能改进。在dotnet / corefx和dotnet / coreclr repos 中的pull请求中搜索“perf”或“performance”，你会发现接近一千个合并的PR改进。其中一些是比较大的同时也很有影响力的改进，而另一些则主要减少了库和运行时的消耗，这些变化一起起作用，保证了能够在.NET Core上更快的运行应用程序。展望未来，性能将成为关注的重点，无论是以性能改进为目标的API还是现有库的性能的改进。
欢迎大家深入了解.NET Core代码库，以便找到影响自己的应用程序和库的瓶颈，并提交PR来修复它们。如果你的问题得到修复，也请将修复程序分享给所有需要的人。
转载请注明出自：葡萄城控件
关于葡萄城
葡萄城是全球控件行业领导者，世界领先的企业应用定制工具、企业报表和商业智能解决方案提供商，为超过75%的全球财富500强企业提供服务。