与UTF8同样重要的是“ISO-8859-1”编码,也被称为“Latin1”(现在公开表示为编码)。Encoding.Latin1通过dotnet/runtime#37550),也非常重要,特别是对于像HTTP这样的网络协议。dotnet/runtime#32994对其实现进行了向量化,这在很大程度上是基于以前对Encoding.ASCII进行的类似优化。这将产生非常好的性能提升,这可以显著地影响诸如HttpClient这样的客户机和诸如Kestrel这样的服务器中的高层使用。
Roundtrip .NET FW 4.8 221.85 ns 209 B
Roundtrip .NET Core 3.1 193.20 ns 200 B
Roundtrip .NET 5.0 41.76 ns 200 B
编码性能的改进也扩展到了System.Text.Encodings中的编码器。来自@gfoidl的PRs dotnet/corefx#42073和dotnet/runtime#284改进了各种TextEncoder类型。这包括使用SSSE3指令向量化FindFirstCharacterToEncodeUtf8以及JavaScriptEncoder中的FindFirstCharToEncode。默认实现。
Regular Expressions
一种非常特殊但非常常见的解析形式是通过正则表达式。早在4月初,我就分享了一篇关于。net 5中System.Text.RegularExpressions大量性能改进的详细博客文章。我不打算在这里重复所有这些内容,但是如果你还没有读过,我鼓励你去读它,因为它代表了图书馆的重大进步。然而,我还在那篇文章中指出,我们将继续改进正则表达式,特别是增加了对特殊但常见情况的更多支持。
其中一个改进是在指定RegexOptions时的换行处理。Multiline,它改变^和$锚点的含义,使其在任何行的开始和结束处匹配,而不仅仅是整个输入字符串的开始和结束处。之前我们没有对起始行锚做任何特殊的处理(当Multiline被指定时^),这意味着作为FindFirstChar操作的一部分(请参阅前面提到的博客文章,了解它指的是什么),我们不会尽可能地跳过它。dotnet/runtime#34566教会FindFirstChar如何使用矢量化的索引向前跳转到下一个相关位置。这一影响在这个基准中得到了强调,它处理从Project Gutenberg下载的“罗密欧与朱丽叶”文本:
Count .NET FW 4.8 False 26.207 ms 1.00
Count .NET Core 3.1 False 21.106 ms 0.80
Count .NET 5.0 False 4.065 ms 0.16
Count .NET FW 4.8 True 16.944 ms 1.00
Count .NET Core 3.1 True 15.287 ms 0.90
Count .NET 5.0 True 2.172 ms 0.13