内联函数的 32 字节限制...不是太小了吗？

我有一个非常小的 C# 代码标记为内联，但不起作用。 我发现最长的函数会生成超过 32 个字节的 IL 代码。 32 字节的限制是否太短？

// inlined
[MethodImpl(MethodImplOptions.AggressiveInlining)] 
static public bool INL_IsInRange (this byte pValue, byte pMin) {
  return(pValue>=pMin);
}

// NOT inlined
[MethodImpl(MethodImplOptions.AggressiveInlining)] 
static public bool INL_IsInRange (this byte pValue, byte pMin, byte pMax) {
  return(pValue>=pMin&&pValue<=pMax);
}

可以改变这个限制吗？

我也在寻找内联函数标准。就您而言，我认为 JIT 优化在决定内联第二个函数之前就超时了。对于 JIT 来说，内联函数不是优先事项，因此它忙于分析您的长代码。但是，如果您将调用置于紧密循环内，JIT 可能会内联它们，因为内部调用将优先于内联。如果您真的关心这种类型的微优化，那么是时候切换到 C++ 了。这是一个全新的勇敢世界等待您探索和利用！

我注意到这个问题在这个答案发布后就被编辑了，这意味着高度的互动性。好吧，我不知道为什么有 32 字节的限制，但保守地说，这似乎正是 CPU 缓存块的大小。真是巧合啊！无论如何，代码优化必须使用特定的硬件配置来完成，最好与其程序集并排保存在额外的文件中。超时策略很愚蠢，因为优化不应该在运行时完成，从而与宝贵的代码执行时间竞争。优化应该在应用程序加载时完成，仅在第一次在计算机上运行时完成，一劳永逸。当检测到硬件配置变化时可以再次触发。再说一次，如果你真的需要性能，就选择 C/C++。 C#不是为性能而设计的，也永远不会把性能放在第一位。与 Java 一样，C# 也是为了安全性而设计的，并且对可能的负面性能影响更加谨慎。