Rate is the frequency at which code is executed. It is not inherently bad, but can be a cause of lag. The reason why it is so high for you is because, as you mentioned, you have infinite loops for each player, so as more players are added, rate will increase, especially if the loops do not exit when the player leaves.
Since your code is reliant on loops, I would focus more on making sure you aren’t making unnecessary cycles, i.e. leaving loops running after the players leave, running 30 times a second when only 10 is necessary, and optimizing the code within the loops.
To get a more indicative measurement of performance, look at activity rather than rate. This is ultimately what measures the load your code puts on systems.
When scripts are destroyed, they are parented to nil and some code inside might still work.
You might need to disable the script before you delete it, thats all.
I’m pretty sure scripts stop running when destroyed, but Nexus said otherwise and I’m not home to check.
As for calculating rate, think of it as the same set of code being executed repeatedly. So only loops increase rate for a sustained time (more than an instant). For example, The following code will have a rate of 30/s
while true do wait() print("Oink") end
While this will have a rate of 60/s
spawn(function()
while true do wait() print("Dogs go ") end
end)
while true do wait() print("oink") end
Do you have a source for this? I’m pretty sure that scripts stop working when they are destroyed.
It depends. If you see a major change in performance then you really should do some optimizations. If not then you should probably be fine with your current code. This happens to my game, and I don’t see any performance issues about it. You should worry more on Script Activity.
This could be my source, i saw it some time ago, so i thought it could be the case here.
But after reading it again, i can be wrong, i dunno. Anyways, its worth a try, might work here.
Sorry if my statement was dumb and misleading.
Naturally. Script objects are only used to facilitate the execution of code. The state of the object, aside from the Disabled state, does not affect the existence of the thread - it’ll continue running. That’s to say, the base class of Scripts is LuaSourceContainer, so the reason behind why such behaviour exists is explained almost directly by it’s name.
This behavior needs to be documented then. I had no idea this happened and I have been destroying scripts for years. Unless I’m missing something and it is documented somewhere?
This behaviour actually is documented, I believe. What’s unclear is why code runs after Destroy is called. I would assume this has to down with Destroy following normal procedure on the physical object and the while loop being handled by the thread scheduler.
I didn’t try the posted code so I don’t know whether it actually works or not. If it does work, this is what I believe.
I’ve been noticing the same thing on my games for the past couple months, it only seems to start increasing as soon as I open the dev console. It’s not happening to only some of my scripts but many of the roblox scripts as well. It will usually eventually get to a point where it just barely increases like it used to, script activity is perfectly fine and goes straight back down to 0 when it shouldn’t be running.
Does that I mean I have to take the extra step doing things like:
local destroyed = false
script:Destroy()
destroyed = true
while wait() do --random loop
if destroyed then break end
--code
end
Or something like:
if script.Parent ~= nil then
--code
end
To prevent code from running (aside from disabling it, as you can’t destroy a disabled script)? I honestly think this is unnecessary behavior, and a script should not run code after calling :Destroy().
You shouldn’t need to worry about doing that kind of stuff, mostly because I would assume you set up your loops to properly break when they aren’t necessary anymore. If you’re not, start getting into that habit. I strongly doubt there are any loops you don’t need to break, though you may have to do something like this in the rare occasion that you do.
Outside of continuous scopes like a loop that’s not being broken properly, chances are that your code is most likely operating in a standard forward scope or in an event-based environment. Destroy will disconnect those connections and perform garbage collection for every finished thread. The only thing you need to worry about post-Destroy is a loop. Everything else will clean itself up.