Are modules faster than bindable events from script to script interaction, or vice versa?
Why I want to know:
I am trying to determine what system I should use for a multitude of doors in a game I’m working on. Where there is a touchpad, when touched, sends a request to a function via a bindable event to swing the door open and closed. I was wondering whether the use of a module script for the door opening logic would result in lower latency; from touchpad invoke to door opening function, or does it not matter?
I have tested the two and it seems modules are slightly faster, but I was wanting a second opinion before having to replace 100+ scripts in doors across 3 maps.
Modules are hands down faster.
Although it’s neglible, module functions do CALLs by pointer as opposed to bindables throwing a pointer reference and some data into thread scheduler to be taken care of eventually.
Dude don’t replace 100+ scripts in doors across 3 maps just for this. The difference is probably fractions of milliseconds. All the lag is probably in communicating from server → client, so if you want to make your doors more reactive, check the touched event on the client and open the door there.
But before you even do that, take a step back: do these high latency doors hurt gameplay considerably? Don’t waste too much time on something trivial.
Edit: Now that I realize it, the greater choppiness is most likely largely in part due to me testing the map creation server with play solo vs. test server on the actual game, so I should run the door translation code on all the clients like you suggested. Although, I am worried that there would be an even greater delay between the door pad being touched and the door being opened; if I had to send a request from the server to the client (not wanting to forget the other issue of running into the door).
True, I suspected the difference would be negligible like @Rerumu mentioned.
The reason I was getting into the mindset of crazy optimization was due to the system being choppier in the actual game vs. the map building server. Which I find sort of odd, since the map building server has much more instances (3 maps) comparable to the game with 1 map and a lobby. With the actual game having pretty much no scripts running (as of now) when the player is on the map.
As the issue stands, there is the problem of the slower door movement (even though the heartbeat is practically the same) and the door not opening as fast; meaning the player runs into the door which is highly undesired.
Well, whatever it is, you should try to find out what your bottleneck actually is, because I guarantee that it isn’t Bindables not being fast enough.
The key to optimization is to find out what’s slow first before you try to speed things up, otherwise you’ll waste a whole bunch of time and things won’t have actually gotten measurably faster.
You should use CollectionService for things like this. Give each touchpad/door a CollectionService tag, and have a single script loop over the items with that tag, connect to its events, etc. Then it’s both elegant code and also easily extendable.
It lets you write code once and use it for many similar objects without having to put a script in each of those objects, or having to scan through the entire workspace/wherever to find all of them. You also don’t have to have them in the same folder/model anymore, as long as they have the tag, they will be found no matter how you organize your workspace.
I don’t see how you want me to compare these things. CollectionService allows you to tag objects with strings and request collections of objects in-game with a specific string. _G is a shared table among all scripts. You can’t use _G to fulfill the use cases of CollectionService or vice versa.
CollectionService tags can be applied to multiple instances. You can tag multiple things with “Something” and then query a list of things that are tagged “Something” without the use of additional scripts inside those objects.
You would need an extra script inside each of those objects to do this, or you would need to store the objects in such a way that you already know where they are. CollectionService allows you to tag objects and, regardless of where they are in the game hierarchy or how your game hierarchy is organized, you will be able to query a list of them.
I recommend reading the example on the wiki to understand how valuable this service is. Saving performance is not a use case of CollectionService, it’s unrelated.
Protip: my doors use a BoolValue called “Open” that the server operates. The clients just listen to this and use TweenService on the Transform property of a Motor6D to move the doors. Looks perfect.
Interesting, as of right now I manually rotate the door about a CFrame which represents the hinge. Even in perfect performance conditions and running on heartbeat:wait() it does not look very smooth, due to how fast I have to rotate it so the player doesn’t run into the door. Have been wondering if I should increase the size of the touch pad so it opens in time, yet I don’t want doors to be opening when people are just walking by the building.
In my version two of the door system I will run the door opening logic on the clients like you and others suggested.
I will also be sure to try your method out, although I will need to learn how to use Motor6D’s.