归功于 Michal Petryka。
▌BitOperations支持附加功能
BitOperations现在支持IsPow2,RoundUpToPowerOf2和提供nint/nuint重载现有函数 。
感谢约翰凯利、霍耀源和罗宾林德纳 。
▌Vector<T>, Vector2, Vector3, 和Vector4改进
Vector<T> 现在支持C# 9 中添加的原始类型nint和nuint原始类型 。 例如 ， 此更改应该可以更简单地使用带有指针或平台相关长度类型的 SIMD 指令 。
Vector<T> 现在支持一种Sum方法来简化计算向量中所有元素的“水平和”的需要 。 归功于伊万兹拉塔诺夫 。
Vector<T> 现在支持一种通用方法As<TFrom, TTo>来简化在具体类型未知的通用上下文中处理向量 。 感谢霍耀源
重载支持Span<T>已添加到Vector2、Vector3和Vector4以改善需要加载或存储矢量类型时的体验 。
▌更好地解析标准数字格式
我们改进了标准数字类型的解析器 ， 特别是.ToString和.TryFormatParse 。 他们现在将理解对精度 > 99 位小数的要求 ， 并将为那么多位数提供准确的结果 。 此外 ， 解析器现在更好地支持方法中的尾随零 。
以下示例演示了之前和之后的行为 。

• 32.ToString("C100")->C132

• .NET 5：我们在格式化代码中人为限制只能处理 <= 99 的精度 。 对于精度 >= 100 ， 我们改为将输入解释为自定义格式 。

• 32.ToString("H99")-> 扔一个FormatException

• .NET 6：抛出 FormatException 。
• 这是正确的行为 ， 但在这里调用它是为了与下一个示例进行对比 。

• 32.ToString("H100")->H132

• .NET 6：抛出 FormatException 。
• .NET 5：H是无效的格式说明符 。 所以 ， 我们应该抛出一个FormatException. 相反 ， 我们将精度 >= 100 解释为自定义格式的错误行为意味着我们返回了错误的值 。

• .NET 5：9007199254740997.0不能完全以 IEEE 754 格式表示 。 使用我们当前的舍入方案 ， 正确的返回值应该是9007199254740996. 但是 ， 输入的最后一部分迫使解析器错误地舍入结果并返回 .09007199254740998 。
  

System.Text.Json
System.Text.Json 提供多种高性能 API 用于处理 JSON 文档 。 在过去的几个版本中 ， 我们添加了新功能 ， 以进一步提高 JSON 处理性能并减轻对希望从NewtonSoft.Json迁移的人的阻碍 。 此版本包括在该路径上的继续 ， 并且在性能方面向前迈出了一大步 ， 特别是在序列化程序源生成器方面 。
▌JsonSerializer 源生成
注意：使用 .NET 6 RC1 或更早版本的源代码生成的应用程序应重新编译 。
几乎所有 .NET 序列化程序的支柱都是反射 。 反射对于某些场景来说是一种很好的能力 ， 但不能作为高性能云原生应用程序（通常（反）序列化和处理大量 JSON 文档）的基础 。 反射是启动、内存使用和程序集修整的问题 。
运行时反射的替代方法是编译时源代码生成 。 在 .NET 6 中 ， 我们包含一个新的源代码生成器作为System.Text.Json. JSON 源代码生成器可以与多种方式结合使用JsonSerializer并且可以通过多种方式进行配置 。
它可以提供以下好处：
? 减少启动时间
? 提高序列化吞吐量
? 减少私有内存使用
? 删除运行时使用System.Reflection 和System.Reflection.Emit
? IL 修整兼容性
默认情况下 ， JSON 源生成器为给定的可序列化类型发出序列化逻辑 。 JsonSerializer通过生成直接使用的源代码 ， 这提供了比使用现有方法更高的性能Utf8JsonWriter 。 简而言之 ， 源代码生成器提供了一种在编译时为您提供不同实现的方法 ， 以使运行时体验更好 。