这种错误检查方法的性能会不会太高

Would this method of error checking be too costly in performance?

本文关键字：性能 会不会 方法 错误 检查      更新时间：2023-10-16

在我的项目中，错误处理和日志记录是通过一个名为Error的类执行的。任何可能需要记录错误或警告的函数或对象方法都会有一个Error & error作为其最后一个函数参数，如果遇到问题，则会调用Error::report(...)。

例如：

float ratioBetweenBounds(  float between, 
float lowerBound, 
float upperBound, 
Error & error)    // <-- 
{
if(upperBound != lowerBound){
return (between - lowerBound) / (upperBound - lowerBound);
}else{
error.report(Error::DivideByZero, __LINE__, __FILE__, lowerBound); // <--
return NAN;
}
}

我的问题是，传递这样一个庞大的引用会给每帧调用大约5000次的小函数带来性能问题吗？我会(也会！)自己对它进行简介，但要过几天我才能(在路上)编译任何东西。也许很明显，它会或不会影响SO的性能，而且分析也不太必要。

到目前为止，这在可读性和调试方面对我来说效果很好，所以如果性能损失很小，我会很高兴的。

(我能看到的唯一开销是添加的分支，但分支预测器应该处理好这一点。它还可能会将一个已经很大的函数翻转过来，这样它就不会内联。不过，除了这些之外，我真的没有任何线索。至少，它看起来与try/catch块将创建的任何小性能命中都相当我想可能会对产生静态偏见

引用通常由编译器作为隐藏指针来实现，因此您实际上是在向函数调用添加一个指针参数。对于一个现代处理器来说，每帧5000次调用真的不算多。继续分析，但我不会担心，除非它被证明是一个问题。

一个可能相关的优化技巧：

通过将error.report设置为冷函数，可以使分支成本低/免费。通过这种方式，编译器将生成代码，"告诉"CPU它不太可能被执行。然而，如果真的这样的话，它会更贵。

// protect it with a macro for other platforms if necessary
#define COLD __attribute__((cold))
static void COLD error() {
// unlikely error code
}

以下文件(适用于GCC)：

cold函数的cold属性用于通知编译器该函数不太可能被执行。功能是针对大小而非速度进行了优化，并且在许多目标上都放置了它进入文本部分的特殊小节，使所有冷函数出现在一起提高的非冷部分的代码局部性程序导致调用代码中的冷函数的路径是被分支预测机制标记为不太可能。就是这样用于标记用于处理不太可能的情况的函数，例如perror，作为cold来改进调用的hot函数的优化在极少数情况下有标记的功能。

然后，如果您可以使用"免费"异常或其他异常，那么在正常情况下，您的代码的其余部分根本不需要因错误检查/报告的存在而对性能产生任何影响。

相关文章：