Is there any notable performance between
Vector2s andVector3s, for example when adding or multiplying them, or when callingNormalize,Transform, orDistance?
Yes, you have one more coordinate so you will use more CPU cycles.
But it is very unlikely that it will ever give you any trouble. XNA 4 is using SIMD extensions for vector math (EDIT: on Windows Phone only), so the implementation is very optimal (on that platform). Except if you're doing very heavy computing, it is very unlikely to ever cause you trouble. You do need Vector3s for your positions because you're now doing 3D (or 2.5D...), so please don't do any premature optimization. This is 97% evil1.
Just a side question, why are there no operators for calculations between Vector3 and Vector2?
Because it makes no sense, mathematically. What would you expect to come out from such calculations? For instance what should happen if you try to add a Vector3 and a Vector2:
[x1, y1, z1] + [x2, y2] = [x1 + x2, y1 + y2, z1] or [x1, y1 + x2, z1 + y2] ?
In this case, you'll typically need to determine by yourself what you want as a third coordinate for the Vector2, and where you wish to add it. For instance this solves the ambiguity:
[x1, y1, z1] + [x2, y2, 0] = [x1 + x2, y1 + y2, z1]
Now it's possible that some parts of your gameplay work only in 2D. If there are cases where you only need 2D coordinates, and if the computing does get really heavy (e.g. 2D physics), you can stick to Vector2s in that specific part of the code to save some precious cycles. You can then easily switch between 2D and 3D coordinates when you need to (e.g. get a scene position from a 2D physics position, or the other way around):
E.g. from Vector2 to Vector3 using this constructor:
Vector2 v2;
Vector3 v3(v2, someDepthValue);
Or from Vector3 to Vector2 using that constructor;
Vector3 v3;
Vector2 v2(v3.X, v3.Y);
1- In1In Donald Knuth's words:
Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.