As one would expect, the reallocations <i>way</i> dominate the costs: here&#x27;s the original program<p><pre><code>    &gt; time .&#x2F;test_cpp
    9999010000
    .&#x2F;test_cpp  2.29s user 0.86s system 99% cpu 3.170 total
</code></pre>
here&#x27;s by replacing []-indexing by at:<p><pre><code>    &gt; time .&#x2F;test_cpp_at
    9999010000
    .&#x2F;test_cpp_at  2.31s user 0.85s system 99% cpu 3.173 total
</code></pre>
and here&#x27;s the second one with vectors reserved to 1000000:<p><pre><code>    &gt; time .&#x2F;test_cpp_at
    9999010000
    .&#x2F;test_cpp_at  1.27s user 0.30s system 98% cpu 1.587 total
</code></pre>
I expect with iterators and iterator transforms an actual C++ developers could get pretty much the same no-alloc thing I got using them in Rust:<p><pre><code>    &gt; time .&#x2F;test_rust
    9999010000
    .&#x2F;test_rust  0.53s user 0.01s system 97% cpu 0.556 total
</code></pre>
And of course you could just remove the entirely unnecessary initial loops and just do the summation on the index values anyway because that&#x27;s what&#x27;s in your vectors, at which point the compiler realises it&#x27;s a constant (or it doesn&#x27;t — I didn&#x27;t actually check ‚ but it just has 10000 iterations to run with 3 additions each so there isn&#x27;t much of a difference between that and a constant on a superscalar GHz+ CPU where everything fits handily into registers because there&#x27;s only two values and a constant):<p><pre><code>    &gt; time .&#x2F;test_cpp
    9999010000
    .&#x2F;test_cpp  0.00s user 0.00s system 45% cpu 0.009 total
</code></pre>
though assuming you didn&#x27;t know the upper bound (or the step) I assume there&#x27;s a formula which gives you the result in constant time.