So I have a list of string values that change roughly every 0.1 seconds, might be slower, but never faster than once every 0.1 seconds.
I’m trying to determine what is the most efficient method for updating things based on the values. I can either loop through the entire list every 0.1 seconds and check for changes that way, or I can setup a .Changed event for each value in the list. Which would be more efficient performance wise? I don’t usually use .Changed, is there anything I should lookout for regarding string value changes?
EDIT: New Question - How does the efficiency of each method change depending how many stringvalues there are? Say 50. Is it better to have 50 .Changed events or iterate through 50 objects?
I’m not sure but it appears .Changed would be the better route. Instead of iterating every .1 seconds and checking if something has changes, just have ROBLOX internals do it for you via .Changed.
I would assume .Changed is better in this scenario because you don’t waste the .1 seconds.
Alright I’ll give that a shot, I just have bad memories from my first days on roblox, where watching .Changed on something like a part would fire 50 times if the part was touched or something dumb like that.
I would make a function that is responsible for changing the values of these strings, and when you fire that function then you can fire your own event stringsChanged or start the loop only when that function is fired.
Ah well actually the strings are changed via the server, and the purpose of the .Changed code is to watch the strings from the client. While I know I could do something similar through a remote event or function, I just don’t really want to pass this kind of data through an event. As Epic mentioned above, gotta rely on roblox internals for some things.
In fact Roblox tries to make the .Changed event efficient. For example, it will not fire if .Position or .CFrame properties changed, because they are supposed to change at a very fast rate which might cause performance problems.
But you can pass whatever you want through an event, what is more: your own event that will be fired by the function responsible for strings change will be more efficient than using a Roblox event for every of these strings.
Right but say I have 50 strings, if I fire the event once for every string that floods the remote event with 500 fires per second. I could also just group the strings up, and fire the event once every 0.1 seconds passing all the strings, but then that causes a huge spike in traffic and raises people’s ping.
But if I leave the stringvalues in say workspace, and change them from the server, roblox’s internal replication will make sure that gets to the client efficiently without any need to fire events.
Once more that brings me back to my original question though for this example, is it better to iterate through 50 objects? or have 50 .changed events?
I would say that 50 event connections is better than iterating, because the Changed events will be fired anyway, regardless you connect to the event or not. And you are only updating when the event is fired, without any redundant updates that would be an effect of the loop.
Well actually Milennium, your method wouldn’t really work for me because not only do the string values change, but there isn’t a constant amount of them.
So I do actually have a folder specifically for them, and I’ll need to watch .Changed when a child is added and disconnect the event when the child is removed.
There aren’t any when the game starts, but it’s entirely possible that by the time the player spawns in, and the particular code starts running, there will already be objects in the folder, so it’s something I gotta look for anyways.
Did you destroy the instance, or just remove it from the workspace? Removing an instance from workspace makes its parent = nil and you have to wait for the garbage collector to check if there are no more references to that instance. If not then GC destroys the instance and deallocates the memory. That’s why it takes some time and in your case, the instance was not destroyed yet by the GC.