AggressiveInlining对IL2CPP的影响

转载：IL2CPPにおけるAggressiveInliningの効果

简述：优化IL2CPP c++代码编译速度

在C#中，可以在方法中加入[MethodImpl(MethodImplOptions.AggressiveInlining)]，要求JIT编译器尽可能内联该方法。

但是，当我使用 Unity 构建 IL2CPP 时，并没有使用 JIT 编译器。所以我试图找出如何处理积极的内联。

如果您检查实际构建的 C++ 代码，使用 AggressiveInlining 的方法具有 C++ 内联。

经过进一步调查，我发现了一个解释这种行为的页面。我将在下面翻译它，因为它在各个方面都有帮助。

当 IL2CPP 生成 C++ 代码时，泛型方法和泛型类中的方法分别放在名为 GenericMethod ??.cpp 和 Generics
??.cpp
的文件中。（其中??代表任意数字。IL2CPP会生成很多不同数字的cpp文件。）非泛型方法会根据程序集名称放在一个文件中，如Assembly-CSharp??.cpp.增加。

默认情况下，C++ 编译器不能跨两个 cpp 文件内联。在 IL2CPP 中，带有 [MethodImpl
(MethodImplOptions.AggressiveInlining)] 的方法在每个使用该方法的 cpp 文件中都被复制。C++
编译器现在可以内联该方法。

当您在 Windows Standalone 的构建中将构建设置设置为“主”进行编译时，将启用链接时间优化。这允许 C++
编译器将内联决策延迟到链接时间。由于链接器了解整个程序，因此可以跨多个 cpp
文件对其进行优化。因此，在运行时使用“Master”设置以获得最佳性能通常是一个好主意。

如果你阅读了这个解释，它似乎比 C# 中的 Aggressive Inlining 有更广泛的作用。特别是，将它附加到从另一个程序集调用的公共方法或泛型中的方法似乎很有用。似乎将构建设置设置为“Master”会更容易和更快。

顺便说一句，IL2CPP 似乎支持 MethodImplOptions.NoInlining 和 MethodImplOptions.NoOptimization 以及 AggressiveInlining。在 Windows 的构建中，NoInlining 被转换为 __declspec (noinline)，NoOptimization 被转换为 __pragma (optimize (“”, off))。我不认为我会使用这么多。

Aggressive Inlining 似乎比我预期的更有效，所以我想积极地使用它。