Source Generators in C# are a powerful feature that allows generating code at compile-time. However, when a Source Generator takes too long to execute, it can significantly slow down the build process. In this article, I'll share how to profile Source Generator performance using MSBuildStructuredLog and JetBrains dotTrace to identify performance bottlenecks.
The core idea is to manually invoke the C# compiler (csc) to compile a project that uses the Source Generator you want to profile. By using dotTrace to profile this compilation process, we can see the execution time of each function within the Source Generator itself. This allows us to pinpoint exactly which parts of the generator are causing performance issues.
C# 的 Source Generator 是一个强大的功能,允许在编译时生成代码。然而,当 Source Generator 执行时间过长时,会显著拖慢构建过程。本文将分享如何使用 MSBuildStructuredLog 和 JetBrains dotTrace 来分析 Source Generator 的性能,从而找出性能瓶颈。
主要思路是手动调用 C# 的编译器(csc)去编译一个使用了你想要分析性能的 Source Generator 的工程。通过用 dotTrace 去分析这个编译进程,我们可以看到 Source Generator 本身内部每个函数的耗时。这样就能精确定位生成器中哪些部分导致了性能问题。
Recently, a friend reported that my open-source high-performance C# binary serialization library Nino would crash on 32-bit platforms (such as armv7 android application built by Unity). I then tracked down and fixed the issue in this commit.
As of the publication of this article, this issue exists in many well-known serialization libraries, such as MemoryPack and MessagePack. In this article, I will share the cause of the issue and the solution.
最近,有朋友反馈了我开源的高性能C#二进制序列化库 Nino 会在32位平台(比如Unity编译出来的armv7安卓应用)出现闪退,随后我对该问题进行了定位和修复。
截止到本文发布,这个问题在很多知名序列化库中都存在,例如MemoryPack和MessagePack,本文分享该问题的原因和修复方法。
I've been working on a project recently that required glow effects for 2D weapons. After implementing a simple solution, I'd like to share the approach and code in this article.
最近在搞一个项目,需要给2D武器做发光特效,于是简单的搞了一下,并在本文分享一下思路和代码
Let's start by creating a fragment shader. Note that this shader supports:
我们先创建一个片元着色器,注意,这个Shader支持: