8KB的C#贪吃蛇游戏热点答疑和.NET7版本

热点,版本,游戏,NET7 · 浏览次数 : 1583

小编点评

## .NET7下的贪吃蛇游戏性能提升分析 以下是您整理的内容的总结: * **.NET7下的贪吃蛇游戏性能提升了**。 * **使用NativeAOT功能可以显著降低程序大小**,例如,使用<PublishAot>选项可以将程序大小缩短到2.15MB,与.NET Core 3.0的65MB相比。 * **.NET 5.0、.NET 6.0的发展**让NativeAOT更加成熟,性能提升更明显。 * **bflat项目可以生成支持无操作系统裸机UEFI启动的C#程序**,极大地提升了开发效率。 **一些细节说明:** * **bflat项目可以针对不同的操作系统和硬件架构构建**,方便开发人员进行性能优化。 * **使用NativeAOT可以生成平台无关的C#可执行文件**,减少开发时代码的平台限制。 * **bflat可以提供性能分析工具**,帮助开发人员发现性能瓶颈。 **其他建议:** * **学习一些性能分析工具**,例如 APM、dotnet tools 等。 * **分享您在性能优化中的经验**,帮助其他开发者提升开发效率。 * **加入性能优化交流群**,与其他志同道合朋友分享经验。

正文

在之前的一篇文章《看我是如何用C#编写一个小于8KB的贪吃蛇游戏》中,介绍了在.NET Core 3.0的环境下如何将贪吃蛇游戏降低到8KB。不过也有很多小伙伴提出了一些疑问和看法,主要是下面这几个方面:

  • .NET Core 3.0可以做到这么小,那么.NET7表现会不会更好?
  • 不敢在生产中用这样的方式,我看CoreRT这个仓库我看已经归档了。
  • 这样子弄太麻烦了,有没有更简单的办法?

今天笔者就给大家一一解答这些问题。

.NET7下的贪吃蛇游戏、

我们知道在.NET7中已经发布了NativeAOT正式的支持,经过.NET5、.NET6的迭代,NativeAOT已经基本成熟可用,那么在.NET7中重新编译这个游戏,有没有什么进步呢?让我们来看一看。

有外网条件的朋友可以看下方的这个GITHUB链接的代码,这个代码就是提交了升级.NET7 NativeAOT的实现:
https://github.com/MichalStrehovsky/SeeSharpSnake/pull/24

使用.NET7单文件发布

为了达到我们的目的,对于这个项目的csproj文件需要有一些小的改动。首先就是将对应的TargetFramework修改为net7.0版本。

此时就已经完成.NET Core 3.1到NET7.0的迁移了,我们运行下面的命令,可以获得一个65MB大小的程序,这个和之前.NET Core 3.1没有什么区别。

dotnet publish -r win-x64 -c Release

开启IL Linker

另外后面的.NET版本支持更好的程序集剪裁,也就是IL Linker工具,我们运行命令行时/p:PublishTrimmed=true选项就可以启用。

dotnet publish -r win-x64 -c Release /p:PublishTrimmed=true

此时我们可以发现,只有11MB大小了,比.NET Core 3.0时代的25MB降低了一半多。

使用NativeAOT功能

然后我们就要开始使用.NET7的NativeAOT功能,需要在项目文件中加入<PublishAot>true</PublishAot>选项。我们加入了一个条件,在平时不开启,只有输入不同Mode的时候才开启。

dotnet publish -r win-x64 -c Release /p:Mode=NativeAOT

此时可以获得一个2.86MB大小的程序,比.NET Core 3.0时代的4.7MB要小了快一半。

使用Moderate模式

继续修改csproj文件,让它支持Moderate模式,也就是使用<IlcGenerateCompleteTypeMetadata>false</IlcGenerateCompleteTypeMetadata>不生成完整的类型元数据,另外也用<IlcOptimizationPreference>Size</IlcOptimizationPreference>让编译器为程序大小进行优化,而不是速度。由于后面的模式也需要支持这个,所以加入了很多条件编译的选项。

dotnet publish -r win-x64 -c Release /p:Mode=NativeAOT-Moderate

结果和上面的一样的2.86MB,也就是说现在NativeAOT应该默认就是Moderate模式。

进一步移除无关数据

接下来我们进一步移除无关的数据。

  • 使用<EventSourceSupport>false</EventSourceSupport>关闭对EventSource的支持
  • 使用<UseSystemResourceKeys>true</UseSystemResourceKeys>删除 System.* 程序集的异常消息。
  • 使用<InvariantGlobalization>true</InvariantGlobalization>删除全球化特定的代码和数据。
dotnet publish -r win-x64 -c Release /p:Mode=NativeAOT-High

此时我们再次发布,可以看到大小已经降低到了2.15MB,比.NET Core 3.0时的3.0MB降低了快30%。

继续移除无关数据

  • 通过<IlcGenerateStackTraceData>false</IlcGenerateStackTraceData>移除堆栈跟踪数据
  • 通过<IlcInvariantGlobalization>true</IlcInvariantGlobalization>移除其它语言的支持
  • 通过<IlcFoldIdenticalMethodBodies>true</IlcFoldIdenticalMethodBodies>将相同的方法体进行合并。

只为我们省下了几百KB,此时大小来到了1.88MB

关闭反射

接下来我们可以继续使用<IlcDisableReflection>true</IlcDisableReflection>来关闭反射,移除掉一些反射的元数据。

dotnet publish -r win-x64 -c Release /p:Mode=NativeAOT-ReflectionFree

关闭反射后,大小来到了1.21MB,这应该是不用骚操作能达到的最小大小了。

和.NET Core 3.0的对比

下图是.NET7和.NET Core 3.0在不同模式下大小的对比,可以看到经过.NET 5.0、.NET 6.0的发展,NativeAOT变得更加成熟了。

模式 .NET Core 3.0 .NET7.0 幅度
单文件发布 65MB 65MB 0%
IL Linker剪裁 25MB 11MB -56%
NativeAOT 4.7MB 2.86MB -40%
NativeAOT-High 3.0MB 1.88MB -38%
关闭反射 1.21MB 1.21MB 0%

关于CoreRT

在博客园的评论中,看到有一位朋友留言,说不敢在生产环境中使用,而且CoreRT已经归档。其实大可放心的使用,CoreRT关闭的原因也正如下面链接仓库里面说的一样,是代码已经合并到runtimelab/nativeaot项目中。
https://github.com/dotnet/corert

而NativeAOT已经从实验室中毕业,合并到dotnet/runtime中了,也就是.NET7看到的<PublishAot>选项,可以关注下面的微软文档。
https://learn.microsoft.com/zh-cn/dotnet/core/deploying/native-aot/

NoRuntime用起来很折腾

另外看到评论区大家吐槽的点就是后面那些骚操作看起来很麻烦,有没有更简单的方式?这个其实是有的,上篇文章的作者推出了bflat这个项目。

bflat是Roslyn(生成.NET可执行文件的"官方"C#编译器)和NativeAOT(née CoreRT)的混合物,NativeAOT(née CoreRT)是基于CoreCLR的.NET的提前编译器。因此,您可以使用高性能 CoreCLR GC 和本机代码生成器 (RyuJIT) 访问最新的 C# 功能。

bflat 将两个组件合并到一个用于 C# 的提前交叉编译器和运行时中。bflat目前可以针对:

  • x64/arm64 基于 glibc 的 Linux(x64 (~CentOS 7) 上为 2.17 或更高版本,arm64 (~Ubuntu 18.04)上为 2.27 或更高版本)
  • arm64 基于 bionic 的 Linux(Android API 级别 21)
  • x64/arm64 Windows (Windows 7 或更高版本)
  • x64 UEFI(仅适用于--stdlib:zero)

对基于 musl 的 Linux 的支持正在开发中。bflat 可以生成本机可执行文件,也可以生成可通过 FFI 从其他语言调用的本机共享库,下面是它的开源地址:
https://github.com/bflattened/bflat

使用NoRuntime模式最小可以做到4KB大小,而且支持无操作系统裸机UEFI启动。

总结

我们可以惊喜的看到NativeAOT经过几年的发展已经逐步走向成熟,另外还有裸机可运行的C#程序,这给了我们很多的想象空间,可能有那么一天C#程序会运行在只有几百KB内存的物联网终端设备上,UEFI启动程序使用C#编写等等。

.NET性能优化交流群

相信大家在开发中经常会遇到一些性能问题,苦于没有有效的工具去发现性能瓶颈,或者是发现瓶颈以后不知道该如何优化。之前一直有读者朋友询问有没有技术交流群,但是由于各种原因一直都没创建,现在很高兴的在这里宣布,我创建了一个专门交流.NET性能优化经验的群组,主题包括但不限于:

  • 如何找到.NET性能瓶颈,如使用APM、dotnet tools等工具
  • .NET框架底层原理的实现,如垃圾回收器、JIT等等
  • 如何编写高性能的.NET代码,哪些地方存在性能陷阱

希望能有更多志同道合朋友加入,分享一些工作中遇到的.NET性能问题和宝贵的性能分析优化经验。目前一群已满,现在开放二群,可以直接扫码进入。

如果提示已经达到200人,可以加我微信,我拉你进群: ls1075

另外也创建了QQ群,群号: 687779078,欢迎大家加入。

与8KB的C#贪吃蛇游戏热点答疑和.NET7版本相似的内容:

8KB的C#贪吃蛇游戏热点答疑和.NET7版本

在之前的一篇文章《看我是如何用C#编写一个小于8KB的贪吃蛇游戏》中,介绍了在.NET Core 3.0的环境下如何将贪吃蛇游戏降低到8KB。不过也有很多小伙伴提出了一些疑问和看法,主要是下面这几个方面: .NET Core 3.0可以做到这么小,那么.NET7表现会不会更好? 不敢在生产中用这样的

C#语言编写的仅有8KB大小的简易贪吃蛇开源游戏

前言 今天大姚给大家分享一款由C#语言编写的仅有8KB大小的简易贪吃蛇开源游戏:SeeSharpSnake。 项目特点 该仓库中的项目文件和脚本可以用多种不同的配置构建相同的游戏,每个配置生成的输出大小也不同。 项目源码运行 F5 运行 SeeSharpSnake项目,查看优秀效果: 构建不同大小版

看我是如何用C#编写一个小于8KB的贪吃蛇游戏的

译者注:这是Michal Strehovský大佬的一篇文章,他目前在微软.NET Runtime团队工作,主要是负责.NET NativeAOT功能的开发。我在前几天看到这篇文章,非常喜欢,虽然它的内容稍微有点过时(还是使用的.NET Core 3.0),不过其中的一些编程技巧和思维方式很受用,特

.NET周报【1月第3期 2023-01-20】

这应该是2023年农历新年前的最后一篇.NET周报,再次预祝大家新年快乐! 国内文章 看我是如何用C#编写一个小于8KB的贪吃蛇游戏的 https://www.cnblogs.com/InCerry/p/building-a-self-contained-game-in-c-under-8-kilo

[转帖]PostgreSQL(三) 内存参数优化和原理(work_mem)内存表 pgfincore插件使用方法

1.常用内存参数 1.1 shared_buffers shared_buffers是PostgreSQL用于共享缓冲区的内存,是由8kb大小的块所形成的数组。PostgreSQL在进行更新、查询等操作时,首先从磁盘把数据读取到内存,之后进行更新,最后将数据写回磁盘。shared_buffers可以