Performance and the Abstraction Penalty

The convenience of views does not come for free. One drawback are the worse compiler error messages which are typical for complex template code. The other disadvantage is the higher complexity of the code the compiler has to deal with. Thus, the well-known abstraction penalty can be expected to incur a performance decrease, depending on the optimization abilities of the compiler.

On the other hand, use of views may reduce the amount of data that is copied around in memory, and can therefore be expected to increase the performance, especially if memory bandwidth is low compared to the processor speed.

The following simplistic test may provide a first idea. Consider a container of pairs of integers:

typedef pair<int,int> value;  
vector<value> container;

To a client (that happens to be interested in minimal values) we want to present the second components via a standard container interface. Without views or smart iterators, one would probably write something like

vector<int> tmp(container.size());  
transform(container.begin(),container.end(),
          select2nd<value>(),tmp.begin()); 
...
return *min_element(tmp.begin(),tmp.end());

The corresponding views solution would be

transform_view<vector<value>,select2nd<value> > 
    tmp(container,select2nd<value>());  
...
return *min_element(tmp.begin(),tmp.end());

This simple test has been studied for different container sizes on a Sun UltraSparc workstation, using GCC 2.95 with and without optimization. The results are shown in Figure 3. A comparison with a broader set of compilers would be interesting, but the other compilers to which we have access (Sun, SGI, MS) are not yet sufficiently standards compliant to compile the code.

Figure 3: Simple performance test without (left) and with (right) optimization.

Obviously, there is an abstraction penalty, especially without optimization, as can be expected. With optimization turned on, the abstraction penalty is significantly decreased, and the smaller memory footprint is often more important. Note that the copying solution starts earlier with swapping.

Given that views and smart iterators share the same performance properties by design, since views are just smart iterator factories, a separate comparison of views and smart iterators is not necessary.