使用.net '内置在类中的特性是否有显著的性能提升?

据我所知，. net框架还没有以一种方式编译，创建钩子到一些否则无法访问的硬件加速或类似的东西，所以对于简单的事情，如KeyValuePair和Tuple，你可能安全的自己滚。

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

他们已经写好了，所以为什么要给自己额外的工作?
1. 微软已经把他们的代码通过了相当严格的审查过程，所以他们的代码很有可能比你的代码更正确、更高效。
2. 其他不得不看你代码的开发人员会确切地知道当他们看到使用标准框架类时应该期待什么，而你自制的东西可能会让他们挠头一段时间。

@gordy也提出了一个很好的观点，即标准框架类被每个人和他们的狗使用，所以仅仅由于以下事实，就会有轻微的性能提升:

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

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

与自制代码相比，这可能仍然具有性能优势，因为代码可能已经被丢弃并缓存。

我建议你大多数时候使用内置类，除非你已经测量过，否则它不够快。

我很确定微软花了很多时间和精力来建立一个快速可靠的东西。你完全有可能打败他们……经过几周的努力。我只是觉得大多数时候不值得花时间。

重写一些东西似乎没有问题的唯一时候是当它没有做所有你想要的。只是要意识到时间成本和相关的难度。

你有希望达到这样的表现吗?有可能，但请记住他们的代码已经经过了充分的测试和优化，所以我认为这是不值得的努力，除非您有一个非常具体的需求，没有一个BCL类型可以直接满足。

并且。net 4.0已经有一个很好的Tuple<>实现。尽管在以前的。net版本中，如果你需要比KeyValuePair更大的东西，你必须自己滚动。

真正的性能增益来自于MS团队构建和测试库方法的事实。你可以非常放心，对象的行为将不会引入bug。

然后就是重新发明轮子的问题。

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

microsoft基类库总是附带一个"重"方法的复杂性解释。所以你可以很容易地决定使用它，或者找到另一个"更快"的算法来实现或使用。

当然，当涉及到繁重的算法(图形、存档等)时，使用较低级别的语言获得的性能提升会派上用场。