in a lot of my functions i return D3DXVECTOR3 so that they can be combined into bigger functions. ie
float rad = GetDot(facingVect(model1),vecttmp));
but which is faster returning a vect from a funtion or in out int the function argumnets
return a vector vs argument vector
The code you just showed apparently returns a float (i.e. scalar), not a D3DXVECTOR3 (i.e. vector). This makes sense; a dot product computes a scalar.
When you do implement the cross product, please just return a value. You are going to need to create scratch space anyway in order to calculate the value properly (without overwriting a vector component before using it for another part of the calculation). So it makes more sense to just write directly into the scratch space and return it. Plus it's much simpler, more sensible and easier to use.
You are going to waste huge amounts of your own time by designing more complicated interfaces because you think they'll let you write a function that runs faster. Even if you're right, you'll often have to sacrifice any gains anyway in order to massage the calling code into shape so it can use the weird interface. Plus, all the time you spend jumping through your own hoops is time you could spend running a profiler, figuring out what's actually slowing down your program and fixing it.
When you do implement the cross product, please just return a value. You are going to need to create scratch space anyway in order to calculate the value properly (without overwriting a vector component before using it for another part of the calculation). So it makes more sense to just write directly into the scratch space and return it. Plus it's much simpler, more sensible and easier to use.
You are going to waste huge amounts of your own time by designing more complicated interfaces because you think they'll let you write a function that runs faster. Even if you're right, you'll often have to sacrifice any gains anyway in order to massage the calling code into shape so it can use the weird interface. Plus, all the time you spend jumping through your own hoops is time you could spend running a profiler, figuring out what's actually slowing down your program and fixing it.
Depends on how "flexible" you want your function to be.
E.g., if you want to calculate and store the facingVec, as well as use it in the GetDot function, you can use references for arguments, rather than D3DXVECTOR3 objects. You're going to do a facing vector calc in any case, so little time is lost storing the result in a reference rather than a local which you return.
That form mimics existing D3DXVec3 functions and may prove to be more compatible. Example:
With facingVect of that form, you can use
rad = D3DXVec3Dot(facingVect(saveFaceVec,model),vecttmp);
The only time "lost" is pushing the local saveFaceVec onto the stack before you call facingVect.
E.g., if you want to calculate and store the facingVec, as well as use it in the GetDot function, you can use references for arguments, rather than D3DXVECTOR3 objects. You're going to do a facing vector calc in any case, so little time is lost storing the result in a reference rather than a local which you return.
That form mimics existing D3DXVec3 functions and may prove to be more compatible. Example:
D3DXVECTOR3& facingVect(D3DXVECTOR3& faceVec, Model& model){ facevec = some_calculation( model ); // this is done whatever the return type is return facevec;}// ... USEAGE:D3DXVECTOR saveFaceVec;// GetDot must take a vector reference as first argumentfloat rad = GetDot(facingVect(saveFaceVec, model), vecttmp);// rad is calculated and saveFaceVec is availableWith facingVect of that form, you can use
rad = D3DXVec3Dot(facingVect(saveFaceVec,model),vecttmp);
The only time "lost" is pushing the local saveFaceVec onto the stack before you call facingVect.
I am pretty sure the compiler will optimise out those returns so it makes no difference in performance. IIRC "Return Value Optimisation" and "Named Return Value Optimisation" are the relevant optimisations done by most modern compilers.
Even without RVO/NRVO, any reasonable cross product implementation will be inlined, and any reasonable Vec3 implementation will have a trivial constructor and destructor, which along with keyhole optimizations will lead to everything but the math being optimized away.
Sneftel speaks truth. Please do not make things harder for yourself (and probably for the compiler as well).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
