Efficient C++ Performance Programming Techniques

是 否 +2 论坛币

k人 参与回答

经管之家送您一份

应届毕业生专属福利!

求职就业群

赵安豆老师微信：zhaoandou666

经管之家联合CDA

送您一个全额奖学金名额~ !

立即领取

感谢您参与论坛问题回答

经管之家送您两个论坛币！

+2 论坛币

Efficient C++ Performance Programming Techniques

By: Dov Bulka; David Mayhew

Publisher: Addison-Wesley Professional

Pub. Date: November 03, 1999

Print ISBN-10: 0-201-37950-3

Print ISBN-13: 978-0-201-37950-1

Pages in Print Edition: 336

Subscriber Rating: [1 Rating]

扫码加我 拉你入群

请注明：姓名-公司-职位

以便审核进群资格，未注明则拒绝

分享0 收藏1 回帖

关键词：Programming performance Techniques EFFICIENT Technique

Chapter 1 Key Points

• Object definitions trigger silent execution in the form of object constructors and destructors. We call it “silent execution” as opposed to “silent overhead” because object construction and destruction are not usually overhead. If the computations performed by the constructor and destructor are always necessary, then they would be considered efficient code (inlining would alleviate the cost of call and return overhead). As we have seen, constructors and destructors do not always have such “pure” characteristics, and they can create significant overhead. In some situations, computations performed by the constructor (and/or destructor) are left unused. We should also point out that this is more of a design issue than a C++ language issue. However, it is seen less often in C because it lacks constructor and destructor support.

• Just because we pass an object by reference does not guarantee good performance. Avoiding object copy helps, but it would be helpful if we didn't have to construct and destroy the object in the first place.

• Don't waste effort on computations whose results are not likely to be used. When tracing is off, the creation of the string member is worthless and costly.

• Don't aim for the world record in design flexibility. All you need is a design that's sufficiently flexible for the problem domain. A char pointer can sometimes do the simple jobs just as well, and more efficiently, than a string.

• Inline. Eliminate the function call overhead that comes with small, frequently invoked function calls. Inlining the Trace constructor and destructor makes it easier to digest the Traceoverhead.

  
  

Chapter 2 Key Points

• Constructors and destructors may be as efficient as hand-crafted C code. In practice, however, they often contain overhead in the form of superfluous computations.

• The construction (destruction) of an object triggers recursive construction (destruction) of parent and member objects. Watch out for the combinatorial explosion of objects in complex hierarchies. They make construction and destruction more expensive.

• Make sure that your code actually uses all the objects that it creates and the computations that they perform. We would encourage people to peer inside the classes that they use. This advice is not going to be popular with OOP advocates. OOP, after all, preaches the use of classes as encapsulated black-box entities and discourages you from looking inside. How do we balance between those competing pieces of advice? There is no simple answer because it is context sensitive. Although the black-box approach works perfectly well for 80% of your code, it may wreak havoc on the 20% that is performance critical. It is also application dependent. Some application will put a premium on maintainability and flexibility, and others may put performance considerations at the top of the list. As a programmer you are going to have to decide the question of what exactly you are trying to maximize.

• The object life cycle is not free of cost. At the very least, construction and destruction of an object may consume CPU cycles. Don't create an object unless you are going to use it. Typically, you want to defer object construction to the scope in which it is manipulated.

• Compilers must initialize contained member objects prior to entering the constructor body. You ought to use the initialization phase to complete the member object creation. This will save the overhead of calling the assignment operator later in the constructor body. In some cases, it will also avoid the generation of temporary objects.

  
  

Chapter 3 Key Points

• The cost of a virtual function stems from the inability to inline calls that are dynamically bound at run-time. The only potential efficiency issue is the speed gained from inlining if there is any. Inlining efficiency is not an issue in the case of functions whose cost is not dominated by call and return overhead.

• Templates are more performance-friendly than inheritance hierarchies. They push type resolution to compile-time, which we consider to be free.

  
  

Chapter 4 Key Points

• If you must return an object by value, the Return Value Optimization will help performance by eliminating the need for creation and destruction of a local object.

• The application of the RVO is up to the discretion of the compiler implementation. You need to consult your compiler documentation or experiment to find if and when RVO is applied.

• You will have a better shot at RVO by deploying the computational constructor.

  
  

Chapter 5 Key Points

• A temporary object could penalize performance twice in the form of constructor and destructor computations.

• Declaring a constructor explicit will prevent the compiler from using it for type conversion behind your back.

• A temporary object is often created by the compiler to fix a type mismatch. You can avoid it by function overloading.

• Avoid object copy if you can. Pass and return objects by reference.

• You can eliminate temporaries by using <op>= operators where <op> may be +, -, *, or /.

  
  

Chapter 6 Key Points

• Flexibility trades off with speed. As the power and flexibility of memory management increases, execution speed decreases.

• The global memory manager (implemented by new() and delete()) is general purpose and consequently expensive.

• Specialized memory managers can be more than an order of magnitude faster than the global one.

• If you allocate mostly memory blocks of a fixed size, a specialized fixed-size memory manager will provide a significant performance boost.

• A similar boost is available if you allocate mostly memory blocks that are confined to a single thread. A single-threaded memory manager will help by skipping over the concurrency issues that the global new() and delete() must handle.

  
  

Chapter 7 Key Points

• The global memory manager (implemented by new() and delete()) is general-purpose and consequently expensive.

• A significant boost is available if you mostly allocate memory blocks that are confined to a single thread. A single-threaded memory manager is much faster than a multithreaded one.

• If you develop a set of efficient single-threaded allocators, you can easily extend their reach into multithreaded environments by the use of templates.

  
  

Chapter 8 Key Points

• Inlining is the replacement of a method call with the code for the method.

• Inlining improves performance by removing call overhead and allowing cross-call optimizations to take place.

• Inlining is primarily an execution-time optimization, though it can also result in smaller executable images as well.

  
  

Chapter 9 Key Points

• Literal arguments and inlining, when combined, provide significant opportunities for a compiler to provide significant performance improvements.

• Inlining may backfire, and overly aggressive inlining will almost certainly do so. Inlining can increase code size. Large code size suffers a higher rate of cache misses and page faults than smaller code.

• Nontrivial inlining decisions should be based on sample execution profiles, not gut feelings.

• Consider rewriting high frequency methods with large static size and small dynamic size to extract their significant dynamic characteristic, and then inline the dynamic component.

• Trivial and singleton methods can always be inlined.