在 .NET 中调用立即返回的方法的开销是多少(因为不满足内部第一个代码的条件)?
我认为无论您的应用程序多么实时,开销都可以忽略不计,并且无论如何分析应该显示事实,可读性更重要,但是一些同事不同意我的观点并说您应该总是避免那些电话......
还有什么意见吗?
在 .NET 中调用立即返回的方法的开销是多少(因为不满足内部第一个代码的条件)?
我认为无论您的应用程序多么实时,开销都可以忽略不计,并且无论如何分析应该显示事实,可读性更重要,但是一些同事不同意我的观点并说您应该总是避免那些电话......
还有什么意见吗?
我敢说,在某些极端情况下它可能很重要——但它们将非常罕见。我同意你的看法:首先写可读性。
请注意,如果方法非常短,JIT 编译器可能会内联它 - 但如果它是一个大方法,而您只是碰巧快速退出,它可能不会。在极端情况下,您可能希望将方法一分为二:一种是短方法(可以内联)来测试方法的其余部分是否有效,另一种是实际完成工作。然后您可以先执行测试,然后调用第二种方法。坦率地说,我不太喜欢它,只有在你发现这确实是一个问题之后才会建议这样做……但至少你有一个建议给你的同事,以解决它确实被证明是的可能性一个问题 :)
作为避免方法调用的原因,您可能需要考虑的一件事是评估参数是否需要很长时间。例如,考虑记录:
Log.Info("I did something: {0}", action.GenerateDescription());
现在,如果GenerateDescription
需要很长时间,如果无论如何都不会发生日志记录,你不想执行它......所以你可以写:
if (Log.IsEnabled(LogLevel.Info))
{
Log.Info("I did something: {0}", action.GenerateDescription());
}
另一种选择是使用委托来推迟评估——尽管这可能有它自己的(小)成本:
Log.Info("I did something: {0}", () => action.GenerateDescription());
或使用方法组转换:
Log.Info("I did something: {0}", action.GenerateDescription);
这可能不是您的同事担心的问题,但值得考虑:)
这取决于您的方法的外观,但编译器也可能“内联”此类方法。因此,可能根本没有开销。