C++性能优化技术：挑战效率极限

需积分: 9 86 浏览量更新于2024-07-23 收藏 1.67MB PDF 举报

“Efficient C++: Performance Programming Techniques 是一本由 Dov Bulka 和 David Mayhew 合著的计算机科学经典著作，由 Addison-Wesley 出版社于1999年11月3日出版，ISBN 为 0-201-37950-3，共336页。” 该书主要挑战了普遍认为 C++ 不适合性能关键应用的观点，即高效 C++ 是一个矛盾的说法。作者通过他们的实际经验，证明了 C++ 具有生成高效程序的巨大潜力。他们揭示了实用的面向对象设计原则和 C++ 编程技术，这些技术能够显著提高程序的性能，并指出在设计和编码过程中常见的性能瓶颈。书中重点关注如何将 C++ 的强大功能和灵活性与高性能和可扩展性相结合，从而达到两全其美的效果。具体讨论的主题包括： 1. 临时对象的管理：临时对象在 C++ 中是常见的，但如果不正确处理，可能会导致不必要的内存分配和拷贝，影响性能。书中可能介绍如何避免这些开销，如使用 `const` 引用、返回引用、RVO（返回值优化）和 NRVO（命名返回值优化）等技巧。 2. 内存管理和对象构造/析构：C++ 中的对象生命周期管理对性能有直接影响。书中可能讲解如何有效地使用智能指针、构造函数和析构函数来控制内存分配和释放，以及避免内存泄漏和不必要的拷贝。 3. 避免隐式类型转换和模板滥用：隐式类型转换可能导致效率下降，而过度使用模板可能导致编译时膨胀。书中可能涵盖如何明智地使用 `static_cast`、`dynamic_cast` 等类型转换，并合理使用模板，以保持代码简洁且高效。 4. 内存对齐和数据结构布局：内存对齐和数据结构的布局对缓存友好性和内存访问速度至关重要。书中可能探讨如何优化数据结构以减少内存访问的开销，例如使用 `alignas` 关键字进行内存对齐，或者调整成员变量的顺序。 5. 函数调用和内联：函数调用会带来一定的开销，尤其是对于小型函数。书中可能介绍何时使用内联函数，以及如何利用编译器的内联优化，以减少调用开销。 6. 并发和多线程编程：在现代多核处理器中，充分利用并发可以极大地提升性能。书中可能涵盖线程安全、同步原语、锁和其他并发策略的使用，以优化多线程程序。 7. STL（标准模板库）的使用：STL 提供了高效的数据结构和算法，但不恰当的使用可能会降低性能。书中可能介绍如何有效利用容器、迭代器和算法，以实现高效的代码。 8. 性能分析和基准测试：为了优化代码，需要了解哪些部分是性能瓶颈。书中可能涵盖如何使用各种工具进行性能分析，以及如何设计和执行基准测试以量化改进。《Efficient C++: Performance Programming Techniques》是一本深入探讨 C++ 性能优化的指南，对于希望在 C++ 应用程序中实现最佳性能的开发者来说，是一本不可或缺的参考书籍。通过学习书中的实践技巧和策略，读者可以更好地理解和掌握如何编写高效、可扩展的 C++ 代码。

• Create a temporary string object from "x = "

• Call itoa(x)

• Create a temporary string object from the char pointer returned by itoa()

• Concatenate the preceding string objects to create a third temporary string

• Destroy all three string temporaries after returning from the debug() call

So we go to all this trouble to construct three temporary

string objects, and proceed to drop them all

over the floor when we find out that trace is inactive. The overhead of creating and destroying those

string and Trace objects is at best hundreds of instructions. In typical OO code where functions are

short and call frequencies are high, trace overhead could easily degrade performance by an order of

magnitude. This is not a farfetched figment of our imagination. We have actually experienced it in a real-

life product implementation. It is an educational experience to delve into this particular horror story in

more detail. It is the story of an attempt to add tracing capability to a complex product consisting of a half-

million lines of C++ code. Our first attempt backfired due to atrocious performance.

Our Initial Trace Implementation

Our intent was to have the trace object log event messages such as entering a function, leaving a function,

and possibly other information of interest between those two events.

int myFunction(int x)

{

string name = "myFunction";

Trace t(name);

...

string moreInfo = "more interesting info";

t.debug(moreInfo);

...

}; // Trace destructor logs exit event to an output stream

To enable this usage we started out with the following Trace implementation:

class Trace {

public:

Trace (const string &name);

~Trace ();

void debug (const string &msg);

static bool traceIsActive;

private:

string theFunctionName;

};

The Trace constructor stores the function's name.

inline

Trace::Trace(const string &name) : theFunctionName(name)

{

if (TraceIsActive) {

cout << "Enter function" << name << endl;

}

Additional information messages are logged via calls to the debug() method.

inline

void Trace::debug(const string &msg)

{

if (TraceIsActive) {

cout << msg << endl;

}

inline

Trace::~Trace()

{

if (traceIsActive) {

cout << "Exit function " << theFunctionName << endl;

}

Once the Trace was designed, coded, and tested, it was deployed and quickly inserted into a large part of

the code.

Trace objects popped up in most of the functions on the critical execution path. On a subsequent

performance test we were shocked to discover that performance plummeted to 20% of its previous level.

The insertion of

Trace objects has slowed down performance by a factor of five. We are talking about the

case when tracing was off and performance was supposed to be unaffected.

What Went Wrong

Programmers may have different views on C++ performance depending on their respective experiences.

But there are a few basic principles that we all agree on:

• I/O is expensive.

• Function call overhead is a factor so we should inline short, frequently called functions.

• Copying objects is expensive. Prefer pass-by-reference over pass-by-value.

Our initial

Trace implementation has adhered to all three of these principles. We avoided I/O if tracing

was off, all methods were inlined, and all

string arguments were passed by reference. We stuck by the

rules and yet we got blindsided. Obviously, the collective wisdom of the previous rules fell short of the

expertise required to develop high-performance C++.

Our experience suggests that the dominant issue in C++ performance is not covered by these three

principles. It is the creation (and eventual destruction) of unnecessary objects that were created in

anticipation of being used but are not. The

Trace implementation is an example of the devastating effect

of useless objects on performance, evident even in the simplest use of a

Trace object. The minimal usage

of a

Trace object is to log function entry and exit:

int myFunction(int x)

{

string name = "myFunction";

Trace t(name);

...

};

This minimal trace invokes a sequence of computations:

• Create the string name local to myFunction.

• Invoke the Trace constructor.

• The Trace constructor invokes the string constructor to create the member string.

剩余204页未读，继续阅读

txp914

粉丝: 22
资源: 702

C++性能优化技术：挑战效率极限

Efficient.C++ Performance Programming Techniques

Efficient.C++Performance.Programming

Efficient C++ Performance Programming Techniques.rar

Efficient C++ Performance Programming Techniques

Efficient C++: Performance Programming Techniques

C++性能优化技巧揭秘：Efficient C++ Performance Programming Techniques

Practical C++ Financial Programming

Hands-On High Performance Programming with Qt 5-2019

C++四书五经 - 05. 标准库

C++四书五经 - 07. 杂项-01

最新资源