std::vector optimization

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)开发者_如何学Python
{
    ...
    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?

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.

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.

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.

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.

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.