tags:

views:

184

answers:

5

Assuming a loop that reads a lot of values from an std::vector is a bottleneck in my program, it has been suggested I change

void f(std::vector<int> v)
{
    ...
    while (...)
    {
        ...
        int x = v[i] + v[j]
        ...
    }
}

to

void f(std::vector<int> v)
{
    int* p_v = &v[0];
    ...
    while (...)
    {
        ...
        int x = p_v[i] + p_v[j]
        ...
    }
}

Will this actually improve performance, by by-passing the [] operator?

+3  A: 

No, not materially. You're making the code harder to read at the expense of (maybe) miniscule performance gains. Regardless, I would be surprised if the compiler doesn't inline the call to operator[] in optimized builds.

If you're unsure, profile it. I imagine it will never show up.

Chris Schmich
+12  A: 

No, that should not affect performance.

Note that you would probably be better off using pass-by-reference-to-const instead of pass-by-value on the vector.

EDIT: For the syntax of that, see @Steve Townsend's answer.

Billy ONeal
Why wouldn't it affect performance? Do you know what std::vector::operator[] does in the standard library that the OP is using?
Ben
@Ben: Considering one of the major design goals for `std::vector<t>` is to have no efficiency overhead over `t[]`, I highly doubt that there's anything other than `return *(base + index);` inside `operator[]` (debug builds excepted of course). Particularly given that the standard says `operator[]` is not bounds checked.
Billy ONeal
+16  A: 

It's more likely (on the face of it) that copying the entire vector every time you call this function is the bottleneck. Why not the following instead?

void f(const std::vector<int>& v)

In any case, never assume where the bottleneck is - measure first, and tune the code that's slow once you know for sure.

Steve Townsend
+1 For measuring before assuming.
Mark B
+3  A: 

The standard answer to almost any question regarding performance is to use a profiler to see if this is a bottleneck and to see whether the change helps. In this case, however, I don't think that's particularly good advice. I've looked at the output from enough compilers for code like this, that I'd almost go so far as to state as a fact that the two will generate identical instruction streams. In theory that could be wrong (while I've played with quite a few compilers, there are certainly other I haven't played with), but in reality I'd be pretty surprised if it is. While there's likely to be an instruction or two up-front (outside the loop) that's different, I'd expect what's in the loop to be identical.

Jerry Coffin
A: 

If you only need sequential access to the contents of the vector (and sadly your example shows seemingly random access, so this wouldn't work, but maybe it's just an example), you may get a significant speed improvement by using iterators to traverse the vector. I've seen this optimization make a noticable difference even on plain arrays with full compiler optimizations turned on.

rmeador