Site map

Home

Documentation
Download
Performance
Links

VTL Performance

The convenience of views comes not for free. One drawback are the worse compiler error messages. 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 typically reduces the amount of data that is copied around in memory, and can therefore be expected to increase the performance, especially if memory bandwith is low compared to the processor speed.

The following very simplistic test may provide some insight:

Consider a container of pairs of integers
typedef pair<int,int> value;
vector<value> container;
is to be searched for the minimal second component. Without views, 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 two different Sun Sparc computers, using GCC 2.95 with and without optimization. The results are shown below:

Discussion

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

Although for more realistic examples the abstraction penalty will be larger because of more complicated views layering, VTL should not lead to a dramatic performance decrease.

Last update: 2000-06-13

Pageviews: 363

Copyright © 2000 by Gary Powell and Konrad-Zuse-Zentrum für Informationstechnik Berlin