As a Roblox developer, it is currently too hard to performantly utilize certain data types as hash keys in tables due to them being uniquely created userdatas.
If Roblox is able to address this issue, it would improve my development experience because it would allow me to map points in space to other values without additional performance cost, and, would generally improve vector performance when used in bulk. The same could be applied to CFrames, Vector2s, UDims, and UDim2s for the same benefits all around, and, likely other values like Color3s.
I feel that
Vector3.new(0, 0, 0) is called twice, the same Vector3 userdata should be returned. The same position should result in the same userdata. This would eliminate the need for an
__eq metamethod for Vector3s since they could just be directly compared which would result in better performance when comparing two vectors, and, it would eliminate the need to index each component of the position when used as a table key. This would likely also save on memory usage, because creating a bunch of the same Vector3s would have a memory complexity of
O(1) whereas currently the memory complexity is
Single dimensional tables are somewhat faster than multi dimensional tables due to the cost of the additional two index operations, so, currently I create a numerical value based on the X Y and Z component of the vector. The problem with this is the cost of indexing each component still stacks up quite a bit, the cost of accessing vector components is significantly more than the cost of a regular table index.
The cost of indexing the components of vectors is also enough that
CFrame:GetComponents() performs nearly 2x-3x faster assuming you have the data type as a CFrame, but, that’s not really related to this feature request necessarily.
I would think that this would also make vectors more intuitive to newer and intermediate programmers since they could be used as table keys. There are a lot of old scripts I wrote that tried to use this, and, I’ve seen it happen quite a bit, and, I think that the fact that two vectors will
== eachother but will appear to only sometimes work in a table can be super confusing, especially because
This has the potential to break scripts, but, only if those scripts rely on the references being different for different vectors, and, I’m not sure where that would generally be useful.