Question about performance concerning multiple events and long waits

Help and Feedback Scripting Support
#1

Making a game where I want to continually spawn items that can be harvested by players. I’m planning on doing the following:

mouse.Button1Down:connect(function()
    if harvestMouseTarget() then
        wait(math.random(60,90))
        respawnCollectible()
    end
end)

I’m not really familiar with how having multiple of these threads running at the same time affects performance. My current understanding of events is that each time the player clicks the mouse button down, assuming he is hovering over a collectible it will create a new thread and wait to respawn the item again.

Will this code negatively affect performance if a ton of these threads are all waiting to respawn things simultaneously?

#2

Anecdotally, multiple threads won’t harm performance (especially when they’re idle like this) unless you have a ridiculous amount of them.

1 Like
#3

Ridiculous amounts being in the thousands and higher?
Thanks for the clarification :slight_smile:

#4

Firstly, Connect not connect

and this is an alternative way to do it

mouse.Button1Down:Connect(function()
    if harvestMouseTarget() then
        delay(math.random(60,90),respawnCollectible)
    end
end)

http://wiki.roblox.com/index.php?title=RBXScriptSignal
http://wiki.roblox.com/index.php?title=Global_namespace/Roblox_namespace#delay

To answer you question, Imo if it’s not multiple loops that does a lot of stuff then you are probably fine.

#5

Being in the tens of thousands from my experience.

EDIT: TENS of thousands, not hundreds.

#6

No need for delay, he’s not using the thread for anything else.

Connect and connect are purely preference and neither will be different from each other so it’s fine to use whatever.

1 Like
#7

The delay and wait methods of doing this will have little to no difference between each other. Both will result in a coroutine being put on the scheduler to be resumed at a certain time. I suspect that wait will be more efficient/performant since delay has to create a new coroutine and start a new function, but that should not significantly affect your game.

Edit
Additionally, the performance impact of having many coroutines on the scheduler will be mostly on memory, and partially dependent upon what variables the coroutines have access to. The performance impact of having many coroutines resumed in a short time period should be insignificant alone; what the resumed scripts do will have a greater impact.

It looks like your coroutine maintains references to no variables and calls a single function. Assuming that function has little cost on its own and won’t be running multiple times a frame, it should be completely fine.

Technically correct. In practice, connect and Connect have no difference. Still, it’s important to avoid using deprecated methods and properties. connect is deprecated:

image

1 Like
#8

I Know

Just in case he wants to use the thread for something else.

Because

He might learn something new from my post

#9

To summarize; threads (like anything else really) are a data type. They’ll sit around doing nothing until queried for it, which means performance issues in their numbers would likely be caused on the thread scheduler itself having to try keeping track.