what about linking one script to that attribute and then firing it, like bindable
Unlikely there will ever be something like that because it just encourages having bad invariants and making your debugging experience worse.
You mentioned the 20% difference in speed but missed the operative part: âand almost 8 times longer than simply storing a reference to an objectâ.
Your code should not be structured in such a way that you need to be doing either . or :FindFirstChild enough that the relative performance of the two is relevant. You should be getting your references upfront and directly using them in your tight loops.
3 Likes
When I wrote that I was more of thinking of situations where the value is used 1-2 times.
To be honest, the 20% slowness is just a scary number when you see it at face value but for most or all cases it doesnât matter. 20% slower than 0.000006499991286545992 is 0.00000779998954385519; this was done only by multiplying the number by 1.2, but when writing real test code itâs accurate.
In an ideal world, we would only have FindFirstChild and dot syntax would be for property access, but obviously that ship has long since sailed so we currently have issues like namespace conflictions thatâve led to bugs in both developer code and CoreScripts, sometimes even just by a username.
Even if you just use the value 1-2 times, the 20% slowness isnât going to deeply affect your systems, and youâll want to write more defensive code that relies less on timing if so. There are a few cases where you want high precision and thatâs when you establish your variables beforehand.
Itâs a good thing this trap wasnât fallen into with attributes and it was instead given a discrete API which already feels nice and clear when written in your code about what itâs doing.
2 Likes
I entirely agree with this statement. Iâve never viewed the fact that âFFC is slower than dot operator by 20%â as significant detriment since time sensitive code often enough isnât going to rely much on FFC anyhow.
1 Like
I am really looking forward to the Instance reference attributes.
And in addition, can the ability to copy and paste attributes be added as a Studio feature? One current advantage of the Value instances is how you can easily copy and paste it, allowing you to quickly add functionality to multiple instances. Attributes are missing this so I hope this can be made into a feature.
1 Like
Package is still not as advanced as it should be. There can be a performance improvement feature for Packages. For an instance, if the Package is a compilation of massive amount of content; being able to filter out which places has this asset and which places donât have this asset would improve this a lot.
This will also allow Package to not be as laggy to update as well.
1 Like
This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.