Is the output in seconds, milliseconds?
It is in seconds, total time //30charlimit//
Sure but that’s because you’re firing like 10.000 times or what? I could fire 1.000.000 and it would be way more than seconds. I’m talking about like 1 function call, that should be only microseconds.
I know, the point is that it’s still faster compared to goodsignal
Fair, I’ll probably try finding a better way than iterating backwards
Yea, I don’t know if there really is a better solution. Would love to hear it though, in case you find it.
I tried cloning the table, but that’s slightly slower (around 10%). At least that doesn’t reverse the order.
Hi man, I know this can sound a bit rude, but can you benchmark it against my module?
That’s not rude.
But it’s pretty hard to benchmark against your module because it’s syntax is so different. I have a whole setup for signal benchmarking, that account for different syntaxes, but yours is too different lol.
Hello, unfortunately if i say the function is yielding it is quite slow at firing, even slower than goodsignal
But for non-yielding calls it is more than 20x faster, so props for that

Anyways, I gotta go sleep now (school tomorrow ), if you have any questions lmk and I’ll answer tomorrow
Hm, that’s odd, 36 seconds? I need to look at my code; that doesn’t seem right. I know creating threads for each function call is slow, but it shouldn’t be that slow
It is that slow lol. That’s why thread recycling is so important.
It highly depends. That’s why there is a yieldCall parameter in my module. You have to explicitly state that your function calls any of the yielding functions. It probably has more to do with lack of yielding in the first place. Because my code will create a separate thread for each Fire() call if yieldCall is set to true. Otherwise, it just runs it through pcall means.
I think the more fair comparison would be if the benchmark function actually yielded. Since that’s when any signal module would create a new thread.
Hi! I had a general question about signal libraries. I’m currently using GoodSignal, but I’ve seen quite a few others out there, like LemonSignal, and similar ones. Do the differences between them really matter? A lot of them seem to promote their performance as a major advantage so is there actually a noticeable difference, or is it mostly just a way to get people to use their own library?
Hello, imo it doesn’t really matter if your stuff doesn’t need it, but for my own usecase I do actually have quite alot of connections (for my game I use around 5 biiig SimpleZone zones so i do need the item entered events to be fast) so this is why I decided to release it so other people can use it too as simplesignal has fast fire times, but otherwise use what you want :V
Hi, I just tested the module for a non-yielding but still somewhat slow function which just does some random sqrt 1000 times, and each one held up the queue by alot This is also why Signal modules use threads, to prevent slow functions from holding up the fire
still dont understand why we are making new signal modules in 2025, haven’t most people grown past this era of their lives. i bet the difference is 1 nanosecond too.
For SimpleSignal it is actually quite a bit faster than other signals for :Fire()
, and of course is easy to maintain :V , keep in mind simplesignal itself has been in use since mid 2024, I just decided to optimize it enough to warrant its own post
Can you provide the benchmark module? I need to test it myself
I shared it at the start of the post to Alex
Can you share the benchmark code? Not too sure what 1 fire and 1 connect means specifically; seperately/at once?
Also, from my own benchmarks SimpleSignal and SignalPlus are around the same speed (Alex does use my method, afterall) (Are you using SimpleSignal version 60?):
I wasn’t able to detect any consistent time advantage between one or the other; pre-creating threads I think is the best that Signal modules can do without micro-optimizations
Also SignalX is only faster cuz it doesn’t use any threads :V