Compiler Inlining Question

Say I have a simple vector class...

Code:

class Vector3{
public:
     Vector3();
     Vector3(float* data);
     Vector3 operator+(const Vector3& vec) const;
     Vector3 operator-(const Vector3& vec) const;
     float dot(const Vector3& vec) const;
     //etc

private:
     float m_data[3];
}

In the constructors, the data is simply copied from the input to the private data member. I use this class quite extensively in some code that needs to run fast so performance considerations are important. A common example is something like this...

Code:

float* data;
//initialize and fill data

Vector3 v1(&data[0]), v2(&data[6]), v3(&data[9]);
float result = v1.dot(v2 - v3);

I was wondering if modern compilers would be able to recognize that the operations performed on v1, v2, and v3 are constant and therefore can be performed directly on the variable data without creating new objects. Or, assuming this really is a bottleneck, should I avoid encapsulation here in the name of speed?

I would suggest you use a profiler to find out where the real issues are.

You will need the following things:
- a complete and debugged program
- real world data
- a profiler

Here's what you do.
- run the program with the test data, under the profiler.
- examine the profile data, identify a hot spot, identify an alternative solution.
- rerun your test suite, does it still pass all the tests? If not, then fix or abandon your "improvement".
- rerun the program with the test data, under the profiler.
- has your change made it better or worse?
-- If it's worse, then back out the change and try again
-- If it's better, is the change worth keeping? Remember, someone else might have to maintain this later on.
- repeat as necessary until the performance is good enough.

Profiling incomplete code with cherry-picked data sets doesn't tell you anything useful about the complete program.

> Or, assuming this really is a bottleneck, should I avoid encapsulation here in the name of speed?
And if your assumption is proved false later on, how much time will you have wasted on writing AND debugging your alternative approach?

> I was wondering if modern compilers would be able to recognize...
There are too many good compilers (with far too many optimisation flags) to even make a wild guess.
I would suggest that if this really bothers you, then write the smallest test case project you can, and examine the assembler generated. Find out which flags (if any) give you the desired effect.

I agree with Salem. The fact that a class is "used quite extensively in some code that needs to run fast" does not make it a performance bottleneck.

Worry about getting your code correct first (i.e. producing the correct output). Then profile it to find hotspots. Very few people can do even a reasonable job of finding hotspots without a profiler. Given a choice between performance and correctness then favour correctness (unless you are working on a hard realtime system but, if you were doing that, you wouldn't ask this question). Code that runs fast but produces incorrect output is worthless, more often than not.