TITLE: efficiency, performance, and design in C++

(Newsgroups: comp.lang.c++.moderated, 1 May 99)


XXX:

>> > > Measurements are in order. Call-by-value is often faster than
>> > > call-by-reference for small objects. As ever, exact figures are
>> > > implementation dependent.


RICHTER: bokr@accessone.com (Bengt Richter)

>       Bottom line: You can't be sure what you're going to get
>besides correct result? So peek at machine language for indications,
>and measure to be sure?


CLAMAGE: Steve Clamage <clamage@eng.sun.com>

This kind of micro-optimization should be investigated only
when you have discovered that performance of the function is
a bottleneck and you have already taken care of the big
items that affect performance.


RICHTER:

>       Does all this mean that to be a good C++ programmer
>one used to have to be a good arms-length assembler programmer
>writing C++ with an intended (even if approximate) machine language
>effect in mind,

CLAMAGE:

Not in general. In fact, the opposite can be true! If you
write code intending to get a particular machine-language
effect, the effort can be counter-productive whenever the
compiler does not generate the code you are expecting. If
you port to a different platform, the tradeoffs can be
entirely different. A different release of a compiler on
the same platform might use a different code-generation
strategy, making your "optimization" worse than useless.

RICHTER:

>       Is "Measurements are in order" the bottom line? If so,
>what do I have to know about the hardware/compiler to make a
>code change with the expectation of a performace change worth
>measuring? Are there things that are still *not* best left to
>the compiler, when we have speculative and out-of-order multiple
>execution pipelines, queued memory accesses, interleaved memory,
>different cache sizes, line sizes, organization, and on and on,
>not to mention multiple cooperating processors?

CLAMAGE:

Worry first about the big things that affect performance:
use the appropriate data structures and algorithms for the
task at hand. A good choice can make orders-of-magnitude
improvement over poor choices.

Worry next about compiler-independent coding techniques.
Scott Meyers covers some of these, as do other books.
Examples are preferring initialization to assignment,
and watching out for temporaries created by passing 
values of class type to and from functions. You can waste
lots of time creating and destroying temporaries,
independent of the compiler and platform.

Worry next -- after you have measured performance, found it
to be inadequate, and discovered the bottleneck -- about
customizing your code to the application. Sometimes you
pay a peformance price for flexibility. Sometimes you are
willing to pay a code maintenance price at some hypothetical
future time to get better performance now. (But you must
make such tradeoffs as a considered decision.)

Only when measurement has shown that you need to look 
for smaller effects should you consider testing the
difference between passing a fundamental type by reference
and by value. And be aware that whatever you find with one
compiler/platform combination might not carry over to any
other compiler or platform.