Signal+｜Insanely optimized script signal

Resources Community Resources
, , ,
#82

:package: Version 3.1.0

:hammer_and_wrench: Changes & fixes:

  • Now uses metatables again.
  • Fixed disconnects.
  • It’s now safe to call Disconnect multiple times.
  • Once and Wait connections now use a variable that is already in the scope instead of indexing the connection for the signal.
  • Minor variable renamings.
  • Minor comment changes and additions.
#83

Is Signal+ memory efficient? I assume since it is fast it probably trades memory over speed, which is not bad, But I would like to know if this trade-off is that big, since I am working on a project that requires the creation of loads of signals.

1 Like
#84

The logic for removing a connection from the signal table is duplicated within the callbackThread function used by Once and Wait, and also exists in the Connection:Disconnect() method

You can create a helper function to reduce redundancy, code readability, and if you want to change how it work,s it would be easier to do so

#85

Hello, the way SimpleSignal works is quite similar to how Signal+ works now so I can answer this question

The answer is no, the tradeoff isn’t too big. You can have 1000 connections on 1 signal and barely experience any memory problems (atleast from my own benchmarks)

The signals themselves are only as big as their connections, so you really shouldn’t worry unless you’re connecting 10k+ times at once, at which point the memory usage starts getting a bit high, but still acceptable.

2 Likes
#86

It was done on purpose. It improves speed.

1 Like
#87

:package: Version 3.2.0

:hammer_and_wrench: Changes & fixes:

  • Now stores reusable threads in a global table again, enabling you to fire connections while their callbacks are still active.
  • Changed module description.
  • Minor comment changes and additions.
#88

Dude, I’ve been testing my module against yours. Before the update, your module was playing at a speed of 52us(3.0.0), and after the update to the new version (3.2.0) - 240us, what the…

#89

I believe you are talking about the Fire. Threads are created on fire not on connect. I believe you are only testing once, not over multiple iterations. The threads are saved, so it’s only the very first fire that is so slow — unless new threads are needed at some point.

It is especially good at connecting (both Connect, Once and Wait).

#90

when I write 10 connections and one Fire, the benchmark starts lagging, although your previous version copes with this in less than 1 ms.

image
image1321×643 55.9 KB

image
Oh, what am I doing, why did I Disconnect signal…
im changed photos

#91

The new version does too. 1 millisecond is 1.000 microseconds

Also why do you have 2 connections for the new version? That’s not fair.

Also it’s not really a fair comparison since you’re preallocating for SignalX, right?
Please explain the 16ExtraThread, 8Pool Threads.

Here’s a proper benchmark:

image
image925×489 57.7 KB

I don’t know how to use your module lol.

#92

I was talking about 10 connections, but there’s only 2

My bad

Yes, you are completely right. I allocate 8 cores for my signal when creating it, and the rest are already being created with the remaining 16 connections (or, if you not yielding in function, only 8 may be created, because the last 8 from the pool will be released by this time)

Okay, actually, the only thing I wanted to do was compare the new signal and the old one. I’ll analyze your code, okay?

1 Like
#93

Yea, I did that for you. As you can see, with connect (10x) and fire combined, the new version is over twice as fast as the old version.

1 Like
#94

I want to ask you, which config should I ideally test your code with? It would be more honest if I check Your code according to Your rules. I will set exactly the same settings for my script.

#95

Just remember that code can be bad at some specific cases but excel in others.
Your benchmark always proves something, just make sure that what it proves really matters, and test different cases.

2 Likes