【问题标题】:Does gsl::not_null hurt performance?gsl::not_null 会影响性能吗?
【发布时间】:2021-04-29 10:29:17
【问题描述】:

C++ Core Guidelines 推荐 gsl::not_null 类型。如I.12: Declare a pointer that must not be null as not_null中所述:

帮助避免取消引用 nullptr 错误。为了提高性能 避免对 nullptr 进行冗余检查。

...

通过在 源、实现者和工具可以提供更好的诊断,例如 通过静态分析发现某些类别的错误,并执行 优化,例如删除分支和空测试。

(如果有兴趣,这是微软对gsl::not_null的实现:GitHub

指南文档说它通过“删除分支和空测试”来提高性能。但是,它也增加了开销,因为如果我想访问底层指针,将调用方法 operator->()operator*()(这不包括 Microsoft 实现在这些方法中运行时检查的开销)。

鉴于不能保证方法内联,文档如何得出净性能增益为正的结论?

【问题讨论】:

  • “鉴于不能保证方法内联,文档如何得出净性能增益为正的结论?”基准测试
  • 虽然不能保证函数调用会被内联,但大多数/所有编译器都会像这样内联包装器代码,因为它知道它应该是“零成本”抽象。
  • 鉴于不能保证方法内联 ...如果您担心这样的实现质量问题,您需要选择一个实现并进行实际测试。谁知道呢,也许你有一个特别糟糕的实现——我们当然不能告诉你。
  • 好的,所以文档确实做了一个理论上不能保证为真的假设。我认为写作背后有一些原因。
  • @t.niese 仅当您定义了GSL_THROW_ON_CONTRACT_VIOLATION

标签: c++ cpp-core-guidelines


【解决方案1】:

但是,它也增加了开销,因为方法 operator->() 和 operator*()

除了,这些函数是内联定义的并且非常小,因此优化器将(很可能)内联扩展它们,这将完全消除潜在的开销。

文档如何得出净性能增益为正的结论?

正如你所引用的,该文档甚至没有承认相关的开销,所以这样的结论是微不足道的。

如果您的意思是文档的作者是如何得出这样的结论的,那么只有那些作者知道。它的范围可能从“他们测量了它的影响”到“他们做了一个假设”。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2012-02-04
    • 2011-01-28
    • 1970-01-01
    • 1970-01-01
    • 2010-09-26
    • 2012-09-29
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多