Further performance optimization.
Here’s an example of a simple function written in plain Lua (it doesn’t make much sense, but it shows how to confuse a compiler):
local function Log(boolA,vecB,vecC)
if boolA then
print(vecB.X,vecB.Y,vecB.Z)
else
print(vecC.X==true and vecC.Y or vecC.Z)
end
end
Lua doesn’t know what boolA, vecB or vecC are. boolA can be any type and has to check whether it’s a true boolean or a non-nil. It only knows that X, Y and Z are values in vecB and vecC, but it has no idea that they are numbers. No optimizations would be possible after the else statement as it doesn’t know that X, Y and Z are numbers, so it still has to check if they are something else. This bad code cannot be optimized much by a JIT compiler without the rest of the code exposed.
Here’s the same example but with types:
local function Log(boolA:boolean,vecB:Vector3,vecC:Vector3)
if boolA then
print(vecB.X,vecB.Y,vecB.Z)
else
print(vecC.X==true and vecC.Y or vecC.Z)
end
end
The compiler immediately knows that boolA is always a boolean, so it doesn’t have to check if it’s non-nil. vecC is a Vector3, so X, Y and Z are numbers, rendering the second print statement easily simplifiable to print(vecC.Z).