在C#中使用params的成本

Question

有没有人建议在C#中使用params进行方法参数传递.我正在考虑为前6个参数进行重载,然后使用params功能进行7次重载.我的理由是避免params功能所需的额外数组分配.这适用于一些高性能的实用方法.有什么建议？创建所有重载是浪费代码吗？

Answer 1

老实说,每个人大喊"过早优化!",我都有点困扰.这就是原因.

1. 你说的很有道理,特别是因为你已经表明你正在开发一个高性能的库.
2. 即使是BCL课程也遵循这种模式.考虑string.Format或的所有重载Console.WriteLine.
3. 这很容易做对.针对过早优化的运动背后的整个前提是,当您为了优化性能而做一些棘手的事情时,您可能会意外地破坏某些内容并使您的代码不易维护.我不明白这是多么危险; 对于您自己以及可能处理您的代码的任何未来开发人员而言,您应该非常直截了当地做什么.

此外,即使您分析了两种方法的结果并且只看到了非常小的速度差异,仍然存在内存分配问题.为每个方法调用创建一个新数组需要分配更多的内存,以后需要进行垃圾回收.在某些需要"几乎"实时行为的场景中(例如算法交易,我所在的领域),最小化垃圾收集与最大化执行速度同样重要.

所以,即使它给我带来了一些挫折:我说去吧.

(对于那些声称"编译器肯定已经做过类似事情"的人来说 - 我不会那么肯定.首先,如果是这样的话,我不明白为什么BCL课程会遵循这种模式,就像我一样已经提到了.但更重要的是,接受多个参数的方法和接受数组的方法之间存在非常大的语义差异.仅仅因为一个可以用作另一个的替代并不意味着编译器会或者应该,尝试这样的替代).

Answer 2

是的,这是.NET框架使用的策略.String.Concat()就是一个很好的例子.它有多达4个字符串的重载,加上一个带有params字符串[]的后备字符串.在这里非常重要,Concat需要快速,并且当他使用+运算符而不是StringBuilder时,它可以帮助用户陷入成功之中.

您将获得的代码重复是价格.您可以对它们进行分析,看看加速是否值得维护头痛.

Fwiw:在.NET框架中有很多这样的微优化.有些必要,因为设计师无法真正预测他们的课程将如何使用.String.Concat()很可能在一个紧密的内部循环中使用,这对于编程性执行是至关重要的,例如,一个只在启动时运行一次的配置阅读器.作为您自己代码的最终用户,您通常可以不必担心这一点.反过来也是如此,当.NET框架代码不太可能被测量时,它显然没有微优化.就像在核心代码很慢时提供重载一样.