Compile times

Nanorange compile times

Nanorange is getting larger, and is now far from the "nano" implementation of Ranges it started out as. Because of this, we want to keep track of how our compile times are growing, to see if it still makes sense to include a collected single header for easy integration. It also makes sense to compare our compile times with the other two ranges implementations, Range-V3 and CMCSTL2, to make sure we're not doing anything too silly.

The test

As a test, we use the following simple test program:

int main()
{
    std::vector<int> vec(10'000'000);
    rng::fill(vec.begin(), vec.end(), 42);

    assert(rng::all_of(vec.begin(), vec.end() [] (int i) {
        return i == 42;
    }));
}

This is then compiled with various different #includes, with the namespace alias rng set appropriately. The various configurations are:

• Specific headers

  This means including only the headers for the algorithms we're using, namely fill and all_of.

• Algorithm header

  This means including the parent algorithm.hpp for Nanorange and Range-V3, and ranges/algorithm for CMCSTL2

• Top-level

  This means the top-level "everything" header, i.e. nanorange.hpp or all.hpp for Range-V3.

For comparison, we also include a test using the STL <algorithm> header. Lastly, for Nanorange we also compare the times with the collected single header, and a precompiled version of the single header.

All tests were conducted using the Unix time command with GCC 8.1 with -std=c++17 on a relatively aged Macbook Pro running OS X. Tests were conducted several times to warm the OS cache; this is to replicate compiling a real project with lots of source files, many of which will use the ranges header.

The results

Configuration	Time (seconds)
STL <algorithm>	0.44
Nanorange, specific	1.20
Nanorange, algorithm	1.46
Nanorange, top-level	1.48
Nanorange, single	1.45
Nanorange, precompiled	0.38
Range-V3, specific	1.52
Range-V3, algorithm	2.39
Range-V3, top-level	3.44
CMCSTL2, specific	1.61
CMCSTL2, algorithm	2.27