使用 .NET 内置类是否会带来显着的性能提升？

Question

快速的小问题...

我知道有时在其他语言中，出于性能原因，库的部分代码是用特定于平台的直接 C 编写的。在这种情况下，您可以通过尽可能使用库代码来获得巨大性能提升。

那么.NET 平台是否这样做呢？ Microsoft 的基类库实现是否以某种我不希望在托管代码中匹配的方式进行了优化？

类似于使用 KeyValuePair 作为类型安全的元组结构而不是编写我自己的东西怎么样？

Answer 1

据我所知，.NET Framework 的编译方式尚未创建一些无法访问的硬件加速或类似内容的挂钩，因此对于诸如 KeyValuePair 和 之类的简单内容Tuple，你可能可以安全地推出自己的。

然而，使用标准框架类还有许多其他优点，如果没有充分的理由，我会犹豫是否要编写自己的类。

1. 它们已经写好了，为什么还要给自己额外的工作呢？
2. 微软已经对他们的代码进行了相当严格的审查过程，因此他们的代码很有可能比你的更正确、更高效。
3. 其他必须查看您的代码的开发人员在看到正在使用的标准框架类时会确切地知道会发生什么，而您自制的东西可能会让他们摸不着头脑。

更新

@gordy也提出了一个很好的观点，即每个人和他们的狗都在使用标准框架类，因此仅仅由于以下事实，就会有轻微的性能增益：

1. 该类可能不必静态实例化或仅针对您的代码进行即时编译，
2. 类的指令更有可能已加载到缓存中，因为它们最近可能已被代码的其他部分使用。通过使用它们，您不太可能需要首先将代码加载到缓存中，并且不太可能将其他可能很快再次使用的代码踢出缓存。

Answer 2

我自己也想知道这一点，但我怀疑情况并非如此，因为您可以“反编译”Reflector 中的所有基础库。

与自制的东西相比，可能仍然具有性能优势，因为代码可能已经被抖动并缓存了。

Answer 3

我建议您大部分时间都使用内置类，除非您已经测量过它不够快。

我很确定微软投入了大量的时间和精力来构建快速可靠的东西。经过几周的努力，你完全有可能击败他们。我只是认为大多数时候不值得花时间。

唯一一次似乎可以重写某些东西的时候是当它没有达到你想要的效果时。只需要注意时间成本和相关的难度即可。

Answer 4

你能希望能达到匹配的表现吗？可能的是，尽管请记住他们的代码已经过全面测试并且经过了极其优化，所以我想说这不是一个值得付出的努力，除非您有一个非常具体的需求，没有可以直接满足的 BCL 类型。

.NET 4.0 已经有了一个很好的 Tuple 实现。但在 .NET 的早期版本中，如果您需要比 KeyValuePair 更大的内容，则必须自己推出。

Answer 5

真正的性能提升来自于 MS 团队构建和测试库方法的事实。您可以非常放心，对象的行为不会引入错误。

然后就是重新发明轮子的问题。你这样做确实必须有一个充分的理由。

Answer 6

主要的性能原因总是在于架构或复杂的算法，语言无关紧要。

Miscrosoft 基类库总是附带“重”方法的复杂性解释。因此您可以轻松决定使用它，或者找到另一个“更快”的算法来实现或使用。

当然，当涉及到繁重的算法（图形、归档等）时，使用较低级别语言所带来的性能提升就会派上用场。