【发布时间】：2009-12-17 19:04:12
【问题描述】：
将一个对象转换为另一个对象的成本是多少？
CustomClass instance = GenericObject as CustomClass
是否应该作为所有代价来避免它？
想看看其他人对此有何看法。我敢肯定这是非常有情境的。
【问题讨论】：
【发布时间】：2009-12-17 19:04:12
【问题描述】：
您应该避免担心特定语言功能对性能的影响，除非您有具体证据（测量结果）证明它们确实会导致问题。
您最关心的应该是代码的正确性和可维护性。
然而，一般来说，只要应用良好的 OO 编程实践并适当地使用泛型（尤其是集合），就可以在 C# 中避免不必要的强制转换。在您确实需要执行强制转换的情况下，它极不可能成为性能瓶颈，除非您在紧密循环中执行此操作或使用可能引发无效强制转换异常的类型。
现实世界中的大多数性能问题都源于算法选择或缺乏对平台本身的认识——而不是特定的语言特性。
【讨论】：
-
也许你可以在最后添加一点关于类型转换的开销的东西。很高兴有建议，但它不能回答问题。
-
另一个问题的好答案。
-
这个答案实际上并没有回答问题。
-
光顾回答。
-
这技术上正确，这不能回答问题。但是，如果您提出这个问题，这就是您需要的答案。您实际上需要直接回答问题的情况是，如果您遇到性能问题，并且发现您键入 cast 的代码行是问题 - 然后您已经有了答案。
不，不应该不惜一切代价避免它。铸造不是很贵。当然，如果你有一个每秒运行一百万次的循环，那么避免强制转换以节省一些性能可能是有意义的，否则它不会真正导致性能问题。
强制转换的真正问题在于它的作弊类型安全。如果你不小心，如果你把东西到处乱扔，引入错误或降低代码的可读性并不难。
【讨论】：
如果您可以使用泛型，那么它是比强制转换更好的解决方案。装箱和拆箱是一项昂贵的操作，应尽可能避免。问题是有时无法避免。
这里的另一个答案还提到，与特定的性能问题或代码可维护性相比，担心装箱是非常微不足道的。我完全同意。
【讨论】：
-
我认为拳击在这里不适用，因为 OP 要求将对象转换为对象，而不是将值转换为对象。
一般来说，临时铸造一个对象的成本在大规模事物中是很低的。但是，如果您多次重复投射对象，那么如果您发现这是导致性能问题的原因，您应该尽量避免它。
毕竟，从 .NET 1.1 到 2.0 的主要改进之一是引入了泛型 - 这解决了对象的强类型列表问题（例如 ArrayList = 基于对象，List = 类型列表）
【讨论】：