共计 15679 个字符,预计需要花费 40 分钟才能阅读完成。
咱们很快乐公布 .NET 6 预览版 7。这是咱们进入(两个)公布候选 (RC) 期之前的最初一次预览。在咱们加快公布速度之前,团队始终在熬夜,全力以赴获取最初一组性能。在这个版本中,您将看到对各种性能的最初一点润色,以及大量的整体公布性能。从这一点来看,团队将专一于将所有性能实现对立(高)品质,以便 .NET 6 为您的生产工作负载做好筹备。
对于生产工作负载的话题,值得揭示大家的是,.NET 网站 和Bing.com自预览版 1 以来始终在 .NET 6 上运行。咱们正在与各个团队(Microsoft 和其余团队)探讨应用.NET 6 RC 进行生产。如果您对此感兴趣并心愿取得无关如何解决该问题的领导,请分割 dotnet@microsoft.com。咱们总是乐于与晚期采纳者交谈。
您能够下载实用于 Linux、macOS 和 Windows 的.NET 6 预览版 7 。
- 安装程序和二进制文件
- 容器镜像
- Linux 软件包
- 发行阐明
- API 差别
- 已知的问题
- GitHub 问题跟踪器
请参阅 .NET MAUI 和ASP.NET Core,理解无关客户端和 Web 应用程序场景新增性能的更多详细信息。
.NET 网站:
https://dotnet.microsoft.com/…
Bing.com:
https://cn.bing.com/
.NET 6 预览版 7:
https://dotnet.microsoft.com/…
安装程序和二进制文件:
https://dotnet.microsoft.com/…
容器镜像:
https://hub.docker.com/_/micr…
Linux 软件包:
https://github.com/dotnet/cor…
发行阐明:
https://github.com/dotnet/cor…
API 差别:
https://github.com/dotnet/cor…
已知的问题:
https://github.com/dotnet/cor…
GitHub 问题跟踪器:
https://github.com/dotnet/cor…
.NET MAUI:
https://devblogs.microsoft.co…
ASP.NET Core:
https://devblogs.microsoft.co…
.NET 6 预览版 7 曾经过测试,并且受 Visual Studio 2022 预览版 3 反对。Visual Studio 2022 使您可能利用为 .NET 6 开发的 Visual Studio 工具,例如在 .NET MAUI 中开发、C# 应用程序的热重载、新的 WebForms 的网页实时预览,以及 IDE 体验中的其余性能改良。Visual Studio Code也反对 .NET 6。Visual Studio Code 的 C# 扩大 的最新版本已针对 .NET 6 预览版 7 进行了更新,并且包含对 C# 10 的反对。
查看 新的对话帖子 ,就最新的 .NET 性能进行工程师对工程师的深刻探讨。咱们还公布了无关C# 10 中的字符串插值和 .NET 6 中的 .NET 6 预览性能 – 通用数学 的帖子。
Visual Studio 2022 预览版 3:
https://dotnet.microsoft.com/…
Visual Studio Code:
https://code.visualstudio.com…
Visual Studio Code 的 C# 扩大:
https://marketplace.visualstu…
新的对话帖子:
https://devblogs.microsoft.co…
C# 10 中的字符串插值和 .NET 6 中的 .NET 6 预览性能 – 通用数学:
https://devblogs.microsoft.co…
.NET SDK:现代化的 C# 我的项目模板
咱们 更新了 .NET SDK 模板 以应用最新的 C# 语言性能和模式。咱们曾经有一段时间没有在新的语言性能方面从新扫视模板了。是时候这样做了,咱们将确保模板在将来应用新的和古代的性能。
新模板中应用了以下语言性能:
- 顶级语句
- 异步 Main
- 全局 using 指令(通过 SDK 驱动的默认值)
- 文件范畴的命名空间
- 指标类型的新表达式
- 可空援用类型
您可能想晓得为什么咱们通过模板启用某些性能,而不是在面向 .NET 6 的 我的项目中默认启用它们。咱们批准您须要做一些工作来将应用程序降级到 .NET 的新版本用于改良平台的默认行为。这使咱们能够改良产品,而不会随着工夫的推移使我的项目文件复杂化。然而,该模型的某些性能可能会具备破坏性,例如可为空的援用类型。咱们不想将这些性能与降级体验分割起来,但心愿将选择权留给您本人,无论何时何地。模板是一个危险低得多的枢轴点,咱们能够在其中为新代码设置新的“良好默认模型”,而简直没有后续影响。通过我的项目模板启用这些性能,咱们取得了两败俱伤:新代码从启用这些性能开始,但降级时现有代码不受影响。
更新了 .NET SDK 模板:
https://github.com/dotnet/tem…
1. 控制台模板
控制台模板展现了最大的变动。因为顶级语句和全局 using 指令,它当初(实际上)变成了一行代码。
// See https://aka.ms/new-console-template for more information
Console.WriteLine("Hello, World!");
同一模板的 .NET 5 版本包含几行相熟的代码,以前甚至单行代码必须应用该构造。
using System;
namespace Company.ConsoleApplication1
{
class Program
{static void Main(string[] args)
{Console.WriteLine("Hello, World!");
}
}
}
控制台模板的我的项目文件也已更改,以启用 可为空援用类型 性能,如下例所示。
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net6.0</TargetFramework>
<Nullable>enable</Nullable>
</PropertyGroup>
</Project>
其余模板还反对可空型、隐式全局应用和文件范畴的命名空间,包含 ASP.NET Core 和类库。
可为空援用类型:
https://docs.microsoft.com/zh…
2.ASP.NET 网页模板
Web 模板也同样缩小了代码行数,应用雷同的性能。
var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();
if (app.Environment.IsDevelopment())
{app.UseDeveloperExceptionPage();
}
app.MapGet("/", () => "Hello World!");
app.Run();
3.ASP.NET MVC 模板
mvc 模板在结构上是类似的。在本例中,咱们已将 Program.cs 和 Startup.cs 合并到一个文件 (Program.cs) 中,从而进一步简化。
var builder = WebApplication.CreateBuilder(args);
// Add services to the container.
builder.Services.AddControllersWithViews();
var app = builder.Build();
// Configure the HTTP request pipeline.
if (app.Environment.IsDevelopment())
{app.UseDeveloperExceptionPage();
}
else
{app.UseExceptionHandler("/Home/Error");
// The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
app.UseHsts();}
app.UseHttpsRedirection();
app.UseStaticFiles();
app.UseRouting();
app.UseAuthorization();
app.MapControllerRoute(
name: "default",
pattern: "{controller=Home}/{action=Index}/{id?}");
app.Run();
4. 模板兼容性
无关应用新模板的兼容性问题,请参阅以下文档。
晚期 .NET 版本不反对模板中的 C# 代码:
https://docs.microsoft.com/zh…
隐式命名空间导入:
https://docs.microsoft.com/zh…
库:用于可空型信息的反射 API
可为空援用类型是编写牢靠代码的重要个性。它实用于编写代码,但不适用于(直到现在)查看它。新的反射 API使您可能确定给定办法的参数和返回值的可空型性质。例如,这些新的 API 对基于反射的工具和序列化程序至关重要。
对于上下文,咱们在 .NET 5 中 向 .NET 库增加了可为空的正文 (并在 .NET 6 中实现),并且正在对本版本的 ASP.NET Core 做同样的事件。咱们还看到 开发人员为他们的我的项目采纳可空型。
可空型信息应用 自定义属性保留在元数据中。原则上,任何人都能够读取自定义属性,然而,这并不现实,因为应用编码是很重要的。
以下示例演示了将新 API 用于几个不同的场景。
新的反射 API:
https://github.com/dotnet/run…
开发人员为他们的我的项目采纳可空型:
https://github.com/jellyfin/j…
自定义属性保留在元数据中:
https://github.com/dotnet/ros…
1. 获取顶级可空型信息
假如您正在实现一个序列化程序。应用这些新的 API,序列化程序能够查看给定的属性是否能够设置为 null:
private NullabilityInfoContext _nullabilityContext = new NullabilityInfoContext();
private void DeserializePropertyValue(PropertyInfo p, object instance, object? value)
{if (value is null)
{var nullabilityInfo = _nullabilityContext.Create(p);
if (nullabilityInfo.WriteState is not NullabilityState.Nullable)
{throw new MySerializerException($"Property'{p.GetType().Name}.{p.Name}''cannot be set to null.");
}
}
p.SetValue(instance, value);
}
2. 获取嵌套的可空型信息
可空型对能够(正式)保留其余对象(如数组和元组)的对象进行了非凡解决。例如,您能够指定数组对象(作为变量,或作为类型成员签名的一部分)必须为非空,但元素能够为空,反之亦然。应用新的反射 API 能够查看这种额定级别的特异性,如以下示例所示。
class Data
{public string?[] ArrayField;
public (string?, object) TupleField;
}
private void Print()
{Type type = typeof(Data);
FieldInfo arrayField = type.GetField("ArrayField");
FieldInfo tupleField = type.GetField("TupleField");
NullabilityInfoContext context = new ();
NullabilityInfo arrayInfo = context.Create(arrayField);
Console.WriteLine(arrayInfo.ReadState); // NotNull
Console.WriteLine(arrayInfo.Element.State); // Nullable
NullabilityInfo tupleInfo = context.Create(tupleField);
Console.WriteLine(tupleInfo.ReadState); // NotNull
Console.WriteLine(tupleInfo.GenericTypeArguments [0].State); // Nullable
Console.WriteLine(tupleInfo.GenericTypeArguments [1].State); // NotNull
}
库:ZipFile 尊重 Unix 文件权限
在类 Unix 操作系统上提取 zip 压缩文件时,System.IO.Compression.ZipFile 类当初能够在创立和设置文件权限期间捕捉 Unix 文件权限。此更改容许通过 zip 来回传送可执行文件,这意味着您不再须要在解压缩 zip 后批改文件权限以使文件可执行。它还尊重用户、组和其他人的读 / 写权限。
如果 zip 不蕴含文件权限(因为它是在 Windows 上创立的,或者应用未捕捉权限的工具,如 .NET 的晚期版本),则提取的文件将取得默认文件权限,就像任何其余新创建的文件。
Unix 文件权限也实用于其余 zip 工具,包含:
Info-ZIP:
https://sourceforge.net/proje…
7-Zip:
https://www.7-zip.org/
.NET 7 晚期性能预览:通用数学
对于 .NET 6,咱们曾经构建了 将 API 标记为“预览中”的性能。这种新办法将使咱们可能跨多个次要版本提供和倒退预览性能。为了应用预览 API,我的项目须要明确抉择应用预览性能。从 .NET 6 RC1 开始,如果您在未明确抉择的状况下应用预览性能,您将看到带有可操作音讯的构建谬误。在当前的版本中,预览性能可能会以颠覆性的形式发生变化。这就是它们须要您抉择增加的起因。
咱们在 .NET 6 中预览的其中一项性能是动态形象接口成员。它容许您在接口中定义动态形象办法(包含运算符)。例如,当初能够实现代数泛型办法。对于某些人来说,此性能将是咱们往年提供的相对杰出的改良。它可能是自 Span<T> 以来最重要的新型零碎性能。
以下示例采纳 IEnumerable<T>,并且因为 T 被束缚为 INumber<T>(可能是 INumber<int>),因而可能对所有值求和。
public static T Sum<T>(IEnumerable<T> values)
where T : INumber<T>
{
T result = T.Zero;
foreach (var value in values)
{result += value;}
return result;
}
这是无效的,因为 INumber<T> 定义了接口实现者必须满足的各种(动态)运算符重载 。IAdditionOperators 可能是最容易了解的新接口,INumber<T> 自身就是从它派生的。
这所有都由一项新性能提供反对,该性能容许在接口中申明动态形象成员。这使接口可能公开运算符和其余静态方法,例如 Parse 或 Create,以及由派生类型实现的那些。请参阅咱们 相干的博客文章 理解更多详情!
提到的所有性能都在 .NET 6 预览版中,不反对在生产中应用。咱们将不胜感激,对于您应用它们的反馈。咱们打算在 .NET 7 中持续倒退和改良通用数学性能以及反对它们的运行时和 C# 性能。咱们心愿对以后体验进行重大更改,这也是新 API 被标记为“在预览中”的局部起因”。
将 API 标记为“预览中”:
https://github.com/dotnet/des…
INumber<T>:
https://github.com/dotnet/run…
运算符重载:
https://docs.microsoft.com/zh…
IAdditionOperators:
https://github.com/dotnet/run…
相干的博客文章:
https://devblogs.microsoft.co…
库:NativeMemory API
咱们增加了通过 System.Runtime.InteropServices.NativeMemory 公开的新 本机内存调配 API。这些 API 与 malloc、free、realloc 和 calloc C API 等效,还包含用于进行对齐调配的 API。
您可能想晓得如何了解这些 API。首先,它们是用于低级代码和算法的低级 API。应用程序开发人员很少会应用这些。思考这些 API 的另一种形式相似于 平台外在API,它们是用于芯片指令的低级 .NET API。这些 API 很类似,但为与内存相干的操作公开了低级 API。
本机内存调配 API:
https://github.com/dotnet/run…
平台外在:
https://github.com/dotnet/des…
库:System.Text.Json 序列化告诉
System.Text.Json 序列化程序当初将告诉作为(反)序列化操作的一部分公开。它们对于默认值和验证很有用。要应用它们,请在 System.Text.Json.Serialization 命名空间内实现一个或多个接口 IJsonOnDeserialized、IJsonOnDeserializing、IJsonOnSerialized 或 IJsonOnSerializing。
这是一个在 JsonSerializer.Serialize() 和 JsonSerializer.Deserialize() 期间验证的示例,以确保 FirstName 属性不为空。
public class Person : IJsonOnDeserialized, IJsonOnSerializing
{public string FirstName{ get; set;}
void IJsonOnDeserialized.OnDeserialized() => Validate(); // Call after deserialization
void IJsonOnSerializing.OnSerializing() => Validate(); // Call before serialization
private void Validate()
{if (FirstName is null)
{throw new InvalidOperationException("The'FirstName'property cannot be'null'.");
}
}
}
以前,您须要实现自定义转换器能力实现此性能。
库:System.Text.Json 序列化属性排序
咱们还通过 System.Text.Json.Serialization.JsonPropertyOrderAttribute 增加了管制属性序列化程序的性能。即指定程序的整数。较小的整数首先被序列化;没有属性的属性的默认排序值为 0。
上面的示例指定 JSON 应按 Id、City、FirstName、LastName 的程序进行序列化:
public class Person
{public string City { get; set;} // No order defined (has the default ordering value of 0)
[JsonPropertyOrder(1)] // Serialize after other properties that have default ordering
public string FirstName {get; set;}
[JsonPropertyOrder(2)] // Serialize after FirstName
public string LastName {get; set;}
[JsonPropertyOrder(-1)] // Serialize before other properties that have default ordering
public int Id {get; set;}
}
以前,序列化程序是由反射程序决定的,它既不是确定的,也不会导致特定的所需程序。
库:应用 System.Text.Json.Utf8JsonWriter“编写原始”JSON
在应用 Utf8JsonWriter 编写 JSON 无效负载时,有时您须要 集成“原始”JSON。
例如:
- 我有一个想要在网络上写出的字节序列,并且我晓得我在做什么(如上面的示例所示)。
- 我有一个 blob,我认为它代表 JSON 内容并且我想将其封装起来,我须要确保封装及其外部内容放弃格局正确。
JsonWriterOptions writerOptions = new() { WriteIndented = true,};
using MemoryStream ms = new();
using UtfJsonWriter writer = new(ms, writerOptions);
writer.WriteStartObject();
writer.WriteString("dataType", "CalculationResults");
writer.WriteStartArray("data");
foreach (CalculationResult result in results)
{writer.WriteStartObject();
writer.WriteString("measurement", result.Measurement);
writer.WritePropertyName("value");
// Write raw JSON numeric value using FormatNumberValue (not defined in the example)
byte[] formattedValue = FormatNumberValue(result.Value);
writer.WriteRawValue(formattedValue, skipValidation: true);
writer.WriteEndObject();}
writer.WriteEndArray();
writer.WriteEndObject();
以下是对上述代码(尤其是 FormatNumberValue)正在执行的操作的形容。为了性能,System.Text.Json 在数字为整数时省略小数点 / 值,如 1.0。基本原理是写入更少的字节有利于性能。在某些状况下,保留十进制值可能很重要,因为消费者将没有小数的数字视为整数,否则视为双精度数。这种新的“原始价值”模型使您能够随时随地进行管制。
集成“原始”JSON:
https://github.com/dotnet/run…
库:JsonSerializer 上的同步流重载
咱们向 JsonSerializer 增加了 新的同步 API,用于将 JSON 数据序列化和反序列化到流。您能够在以下示例中看到这一点。
using MemoryStream ms = GetMyStream();
MyPoco poco = JsonSerializer.Deserialize<MyPoco>(ms);
通过承受 JsonTypeInfo<T> 或 JsonSerializerContext 实例,这些新的同步 API 包含与新的 System.Text.Json 源生成器 兼容和可用的重载。
新的同步 API:
https://github.com/dotnet/run…
System.Text.Json 源生成器:
https://devblogs.microsoft.co…
库:删除了 System.Text.Json.Nodes.JsonNode 对 dynamic 的反对
JsonSerializer 中对 C#dynamic类型的反对已被删除。咱们在 Preview 4 中增加了 dynamic 反对,但起初确定是一个蹩脚的设计抉择,包含使其成为 JsonNode 类型的必须依赖项。
此更改被认为是从 .NET 6 preview 到 preview standpoint 的 重大更改,但不是从 .NET 5 到 6。
dynamic:
https://docs.microsoft.com/zh…
重大更改:
https://github.com/dotnet/doc…
库:System.Diagnostics Propagators
在过来的几年里,咱们始终在改良对 OpenTelemetry 的反对。实现弱小反对的要害方面之一是确保须要参加遥测生产的所有组件以正确的格局生成网络标头。这真的很难做到,尤其是随着 OpenTelemetry 标准的变动。OpenTelemetry 定义了 流传 概念来帮忙解决这种状况。咱们正在采纳流传来启用用于标头自定义的通用模型。
更宽泛概念的背景:
- OpenTelemetry标准——分布式跟踪数据结构的内存示意。
- OpenTelemetry Span — 用于跟踪的构建块,由 .NET 中的 System.Diagnostics.Activity 代表。
- W3C TraceContext — 对于如何通过家喻户晓的 HTTP 标头流传这些分布式跟踪数据结构的标准。
以下代码演示了应用流传的个别办法。
DistributedContextPropagator propagator = DistributedContextPropagator.Current;
propagator.Inject(activity, carrier, (object theCarrier, string fieldName, string value) =>
{// Extract the context from the activity then inject it to the carrier.});
您还能够抉择应用不同的流传器。
// Set the current propagation behavior to not transmit any distributed context information in outbound network messages.
DistributedContextPropagator.Current = DistributedContextPropagator.CreateNoOutputPropagator();
OpenTelemetry:
https://devblogs.microsoft.co…
流传:
https://opentelemetry.lightst…
OpenTelemetry:
https://opentelemetry.io/
OpenTelemetry Span:
https://opentelemetry.lightst…
System.Diagnostics.Activity:
https://docs.microsoft.com/zh…
W3C TraceContext:
https://www.w3.org/TR/trace-c…
DistributedContextPropagator 抽象类确定分布式上下文信息在遍历网络时是否以及如何编码和解码。编码能够通过任何反对键值字符串对的网络协议传输。DistributedContextPropagator 将值注入到载体中并从载体中提取值作为键 / 值字符串对。通过增加对流传器的反对,咱们实现了两件事:
- 您不再须要应用 W3C TraceContext 标头。您能够编写自定义流传器(即,应用您本人的标头名称,包含基本不发送它们),而无需 HttpClient、ASP.NET Core 具备此自定义格局的先验常识的库
- 如果您应用自定义传输(例如音讯队列)实现库,则当初能够反对各种连贯格局,只有您反对发送和接管文本映射(例如 Dictionary<string, string>)
大多数利用程序代码不须要间接应用此性能,然而,如果您应用 OpenTelemetry,您很可能会在调用堆栈中看到它。如果关怀跟踪和因果关系,一些库代码将心愿参加此模型。
W3C TraceContext:
https://www.w3.org/TR/trace-c…
库:加密操作的简化调用模式
.NET 加密和解密例程是围绕流设计的,没有定义无效负载何时曾经在内存中的真正概念。SymmetricAlgorithm 上新的 Encrypt- 和 Decrypt- 办法减速了内存中曾经存在的状况,旨在为调用者和代码审查者提供清晰的信息。此外,它们反对从跨度读取和向跨度写入。
新的简化办法提供了一种应用加密 API 的间接办法:
private static byte[] Decrypt(byte[] key, byte[] iv, byte[] ciphertext)
{using (Aes aes = Aes.Create())
{
aes.Key = key;
return aes.DecryptCbc(ciphertext, iv);
}
}
应用新的 Encrypt- 和 Decrypt-methods,仅应用来自 SymmetricAlgorithm 实例的 key 属性。新的 DecryptCbc 办法反对抉择填充算法,但 PKCS#7 常常与 CBC 一起应用,因而它是默认参数。如果您喜爱更清晰,只需指定它:
private static byte[] Decrypt(byte[] key, byte[] iv, byte[] ciphertext)
{using (Aes aes = Aes.Create())
{
aes.Key = key;
return aes.DecryptCbc(ciphertext, iv, PaddingMode.PKCS7);
}
}
您能够看到现有模式(应用 .NET 5)须要更多的管道能力取得雷同的后果。
private static byte[] Decrypt(byte[] key, byte[] iv, byte[] ciphertext)
{using (Aes aes = Aes.Create())
{
aes.Key = key;
aes.IV = iv;
// These are the defaults, but let's set them anyways.
aes.Padding = PaddingMode.PKCS7;
aes.Mode = CipherMode.CBC;
using (MemoryStream destination = new MemoryStream())
using (ICryptoTransform transform = aes.CreateDecryptor())
using (CryptoStream cryptoStream = new CryptoStream(destination, transform, CryptoStreamMode.Write))
{cryptoStream.Write(ciphertext, 0, ciphertext.Length);
cryptoStream.FlushFinalBlock();
return destination.ToArray();}
}
}
库:全局不变模式下的残缺案例映射反对
全局不变模式 使您可能打消应用程序对全局数据和行为的依赖,以换取较小的应用程序(次要在 Linux 上)。咱们 改良了全局不变模式 以反对残缺 Unicode 字符集的大小写映射。以前,此模式仅反对 ASCII 范畴字符用于 String.ToUpper、String.ToLower 和字符串比拟以及应用IgnoreCase 选项进行搜寻等操作。
基于 Alpine 的 .NET 容器镜像是咱们 默认启用全局环境模式 的惟一环境。
全局不变模式:
https://github.com/dotnet/run…
改良了全局不变模式:
https://docs.microsoft.com/zh…
IgnoreCase:
https://docs.microsoft.com/zh…
默认启用全局环境模式:
https://github.com/dotnet/dot…
运行时:W^X(写或执行)反对所有平台和架构
运行时当初有一种模式,它不会同时创立或应用任何可写和可执行的内存页面。所有可执行内存都映射为只读。此性能已在 macOS(实用于 Apple Silicon)上启用。在 Apple Silicon 机器上,同时可写和可执行的内存映射是被禁止的。
此性能现已在所有其余平台上启用和反对,作为可选体验。在这些平台上,可执行代码的生成 / 批改是通过独自的读写内存映射实现的。这对于 JIT 代码和运行时生成的帮忙程序都是没错的。这些映射是在与可执行代码地址不同的虚拟内存地址处创立的,并且仅在执行写入时存在很短的工夫。例如,JIT 当初将代码生成到暂存缓冲区中,在整个办法被 JIT 之后,应用单个内存复制函数调用将代码复制到可执行内存中。并且可写映射生命周期仅逾越内存复制的工夫。
能够通过将环境变量 DOTNET_EnableWriteXorExecute 设置为 1 来启用此新性能。此性能在 .NET 6 中是可选的,因为它有具备启动回归(Apple Silicon 除外)。在咱们的 ASP.Net 基准测试中,当应用 Ready To Run (R2R) 编译时,回归约为 10%。然而,在启用和不启用该性能的状况下,测量的稳态性能雷同。对于启动性能不重要的应用程序,咱们倡议启用此性能以进步其提供的安全性。咱们打算在 .NET 7 中解决性能回归问题,并在那时默认启用该性能。
运行时:CodeGen 变更日志
在预览版 7 中的代码生成中进行了以下更改。
1. 社区 PR
以下 PR 均来自@SingleAccrtion:
- 在 32 位指标运行时优化 CAST(int <- long)#53040
https://github.com/dotnet/run…
- 打消对小类型运行时的链式转换 #52561
https://github.com/dotnet/run…
- 从除法变形运行时中删除一些不须要的代码 #53464
https://github.com/dotnet/run…
- 修复长 muls 运行时变形中的 CQ 回归和正确性谬误 #53566
https://github.com/dotnet/run…
- 优化窄存储运行时不要打消 FP 类型的强制转换 #53667
https://github.com/dotnet/run…
- 挪动“不要零扩大 setcc”优化以升高运行工夫 #53778
https://github.com/dotnet/run…
- 禁用实现定义的强制转换运行时的折叠 #53782
https://github.com/dotnet/run…
- 为 VNF_MapStore 和 VNF_MapSelect 运行时增加 args 形容 #54108
https://github.com/dotnet/run…
- 将 cgt.un(op, 0) 导入为 NE(op, 0) 运行时 #54539
https://github.com/dotnet/run…
- 应用本地断言道具在返回运行时省略强制转换 #55632
https://github.com/dotnet/run…
@SingleAccrtion:
https://github.com/SingleAccr…
2. 动静 PGO
以下 PR 反对 动静 PGO 我的项目。
- [JIT] 改良 inliner:新启发式,依赖 PGO 数据运行时 #52708
https://github.com/dotnet/run…
- 内联:扩大配置调用站点的 IL 限度,容许内联交换机。运行时 #55478
https://github.com/dotnet/run…
- JIT:动态类推导失败时启用 GDV。运行工夫 #55660
https://github.com/dotnet/run…
动静 PGO 我的项目:
https://github.com/dotnet/run…
3.LSRA
以下 PR 反对LRSA 我的项目。
- 在定义时溢出单定义变量以防止进一步溢出运行时 #54345
https://github.com/dotnet/run…
- 在 minopts 中将 vars 标记为 do not enreg。运行时 #54998
https://github.com/dotnet/run…
LRSA 我的项目:
https://github.com/dotnet/run…
4. 循环优化
以下 PR 改良了循环优化。
- 改良循环克隆,调试改良运行时 #55299
https://github.com/dotnet/run…
- 反对应用构造索引表达式运行时的数组克隆循环 #55612
https://github.com/dotnet/run…
- 将 RyuJIT 优化的最大循环从 16 减少到 64。runtime#55614
https://github.com/dotnet/run…
5. 构造
以下 PR 改良了构造解决。
- 在 win x64 上注册构造。运行工夫 #55045
https://github.com/dotnet/run…
- Enreg 构建 x86 窗口。运行工夫 #55535
https://github.com/dotnet/run…
- 在所有平台上默认启用 StructEnreg。运行工夫 #55558
https://github.com/dotnet/run…
- 改良 TryTransformStoreObjAsStoreInd 优化。运行时 #55727
https://github.com/dotnet/run…
6. 优化
以下 PR 改良了个别优化。
- 布尔逻辑中的“==0”优化 #13573 runtime#49548
https://github.com/dotnet/run…
- 尾调用运行时时容许隐式扩大 #54864
https://github.com/dotnet/run…
结束语
咱们正处于发行版的那个时候,咱们思考实现新性能和改良。干得好,团队。这是另一季 .NET 预览的完结。
咱们持续心愿并依赖您的反馈。咱们将把 .NET 6 的其余部分集中在回归(性能和性能)和新性能中发现的谬误上。在大多数状况下,性能改良须要期待 .NET 7。请分享您的任何和所有反馈,咱们很乐意对其进行分类。
感激所有为 .NET 6 成为另一个平凡版本做出奉献的人。
感谢您成为 .NET 开发人员。
扫码关注微软 MSDN,获取更多微软一手技术信息和官网学习材料!