【问题标题】:Reduce the cost of abstraction layer by inlining通过内联降低抽象层的成本
【发布时间】:2013-03-02 11:56:39
【问题描述】:

在我的项目中,我有一些像这样的抽象层:

 Vector3 normalizeVector(Vector3 v);

 Vector3 vectorMultiplyMatrix(Vector3 v, Matrix3 m);

哪些只是平台特定数学库(如 DirectXMath)的“代理”函数。

我的问题是如何降低这些层的成本?通过使所有这些函数内联,将完全消除调用它们而不是直接调用特定于平台的函数的成本吗?

谢谢

【问题讨论】:

    标签: c++ interface abstraction


    【解决方案1】:

    添加一个新的抽象级别(代理、外观等)意味着将一堆函数调用捆绑在另一个抽象级别中的成本可以忽略不计。将数据传递给它们的方式可能会给您带来麻烦,尤其是在使用复杂的对象、容器等时。

    Vector3 normalizeVector(Vector3 v);
    

    在每次调用时创建传递的Vector3 对象的副本。如果您遇到性能问题,请通过将按值传递更改为按const 参考传递来避免创建副本:

    Vector3 normalizeVector(const Vector3& v);
    

    这个函数的这个新原型表示:“我需要一个对现有有效Vector3 对象的引用,我将使用但不会更改”

    除非您真的遇到性能问题,否则不要优化您的代码。 过早的优化一直都是邪恶的,而且永远都是。

    【讨论】:

    • 我已经通过引用传递了参数,问题中的代码只是我作为示例编写的代码。无论如何,谢谢:) 我对内联的效果更感兴趣......
    【解决方案2】:

    暴露函数体会给编译器一个机会,通过内联消除函数调用。

    它是否真的会接受它取决于它的内部启发式:内联可能会扩大生成代码的整体大小,使其对缓存不太友好,并最终否定消除调用的好处。

    有一些特殊的关键字(例如 VC++ 下的__forceinline)可以用来覆盖编译器的成本/收益分析,但编译器在这些决策上的正确性往往比程序员多!

    使用profile-guided optimization 可以帮助编译器根据程序的实际使用模式做出更好的优化决策,包括哪些函数“热”到足以内联,哪些函数“冷”应该不理会。​​p >


    记住一个特别强大的技术是template metaprogramming。这个想法是将尽可能多的计算推到编译时。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2016-02-29
      • 1970-01-01
      • 2022-01-16
      • 2022-01-14
      • 2021-11-08
      • 2018-03-28
      • 2020-08-20
      相关资源
      最近更新 更多