Generic Programming has always been about performance. One should be able to write generic algorithms using natural abstractions and have those generic algorithms compile to efficient, concrete instances. The C++ template mechanism allows us to do this, and so should concepts.
ConceptGCC took a big step in this direction today, now that it properly implements the parameter-passing semantics of the upcoming “joint” concepts proposal. The Indiana proposal used to allow signatures to receive parameters by-value, which implies extra copies that made concept-constrained templates less efficient than unconstrained templates. The “joint” proposal takes signature parameters of type T and transforms them into const T& parameters, eliminating these copies (originally suggested by Alexander Stepanov). The following table provides some timing information comparing the performance of ConceptGCC with and without concepts support enabled. I used the search_n test from the libstdc++ performance testsuite for evaluation purposes.
| search_n.cc | Concepts | No Concepts | Relative Performance |
|---|---|---|---|
| Forward Iterator | 716 | 654 | Concepts are 9.48% slower |
| Random Access Iterator | 324 | 324 | No difference |
In the one case, concepts slow us down by almost 10%; in the other, concepts do not matter at all. While 10% is unacceptable for a production compiler, it is far better than what we had previously: at one point, ConceptGCC with concepts was five times slower than without concepts. The change to pass-by-reference and the move to GCC 4.1 now has us within 10%. I am confident that we will close that gap when we are feature-complete and have time to dedicate to optimization.
