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

Question

快速的小问题......

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

.NET平台也这样做吗？ Microsoft的基类库实现是否以某种方式进行了优化，我无法在托管代码中进行匹配？

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

Answer 1

据我所知，.NET Framework的编译方式并没有创建一些其他无法访问的硬件加速或类似的东西，因此对于像KeyValuePair和{{1这样的简单事物你可能安全地自己动手。

然而，使用标准框架类还有许多其他优点，我会毫不犹豫地编写自己的优点。

1. 他们已经写好了，为什么要给自己额外的工作？
2. 微软已经通过一个非常严格的审查程序来处理他们的代码，因此他们的代码很可能比你的代码更正确，更有效。
3. 其他必须查看代码的开发人员会在他们看到标准框架类被使用时确切地知道会发生什么，而您自己酿造的东西可能会让他们暂时不知所措。

更新

@gordy也提出了一个很好的观点，标准框架类正在被所有人和他们的狗使用，因此只会因为以下事实而获得轻微的性能提升：

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

Answer 2

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

与自制内容相比，可能仍然存在性能优势，因为代码可能已经被嵌入并缓存。

Answer 3

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

我很确定MS花了很多时间和精力来建立快速可靠的东西。经过几周的努力，你完全有可能击败他们。我大部分时间都认为这不值得。

重写某事的唯一时机就是它没有完成你想要的所有事情。请注意时间成本和相关难度。

Answer 4

你能不能希望与表现相匹配？可能，虽然请记住他们的代码已经过全面测试和极度优化，所以我说这不值得努力，除非你有一个非常具体的需求，就是没有直接满足的BCL类型。

.NET 4.0已经实现了良好的Tuple<>。虽然在以前的.NET版本中，如果你需要比KeyValuePair更大的东西，你必须自己动手。

Answer 5

真正的性能提升来自于MS团队构建并测试了库方法的事实。您可以非常放心地保证物体在不引入错误的情况下表现出来。

然后有重新发明轮子的问题。你真的必须有充分的理由这样做。

Answer 6

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

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

当涉及到繁重的算法（图形，存档等）时，那么从较低级别语言获得的性能提升就会派上用场。