HenderickJoin Date: 2007-12-10
Post Count: 1523 |
Another question regarding remote objects, but I was wondering if there was any actual difference between using 2 remote events and a single remote function, and perhaps the efficiency of either.
When a function is connected to a remote event and it is fired, the function still receives the player who fired it as a parameter. The function can then respond to the client who fired the event with the input it received by firing a second event that a function on the local client is connected to. It seems this has the same effect of using a single remote function to preserve input and return output in the same function call, but is it truly any different? (like maybe the effects of a lack of a yield or need to wait for a response makes using 2 remote events more effective) |
|
OldGoldieJoin Date: 2010-08-17
Post Count: 8210 |
Do you mean having one single event for everything versus having multiple events for everything?
I believe it's personal preference, but might have a slight performance difference.
|
|
HenderickJoin Date: 2007-12-10
Post Count: 1523 |
Yes, that's the general gist. It's basically differentiating between the use of the specific RemoteEvent object versus the RemoteFunction object. With a RemoteFunction, the caller has to wait for the callee to return output in response to the caller's input. With a RemoteEvent, there is no need for the caller to wait for anything (which might have some generally beneficial effects like with the yield I mentioned earlier?) If the developer still wants to simulate RemoteFunction behavior, he could simply use a second RemoteEvent to send the output of the first RemoveEvent to the original caller. This brings another interesting question; is the use of a RemoteFunction somehow more secure than using 2 RemoteEvents in that it forces a yield?
Also, I was interested in the specifics of that slight performance difference, actually.
|
|
OldGoldieJoin Date: 2010-08-17
Post Count: 8210 |
If you want to test it, you can make a remote event that does this:
client -
fireserver(os.time())
server-
print(os.time()..":"..players os.time)
And do that again, but put like 10, or 20 or so like "if func == "whatever" then" or however you would do it.
You should run them maybe 10 times each because of normal server delay.
|
|
HenderickJoin Date: 2007-12-10
Post Count: 1523 |
Thanks for the input!
I tried what you said and the differences turned out to be indeed very negligible (to the point that putting stats here wouldn't really show much of anything at all). I connected FireServer and InvokeServer to Heartbeat to maximize the number of trials to measure the differences.
I guess, don't really worry about which one to use? RemoteFunctions are probably better for the specialization they provide in this case. |
|
|
use tick() instead of os.time() and run your testing again
os.time() only has full second values so for any fairly small difference it won't show |
|
chimmihcJoin Date: 2014-09-01
Post Count: 17143 |
You'll run into time zone differences.
|
|
HenderickJoin Date: 2007-12-10
Post Count: 1523 |
-- server script----------
-- RemoteEvent
game:GetService("ReplicatedStorage").RemoteEvent.OnServerEvent:Connect(function(player, newTick)
print((tick() - newTick)) for i=1,150 do wait() end game:GetService("ReplicatedStorage").RemoteEvent2:FireAllClients(newTick)
return newTick
end)
-- RemoteFunction
--[[game:GetService("ReplicatedStorage").RemoteFunction.OnServerInvoke = function(player, newTick)
print(tick() - newTick) for i=1,150 do wait() end --game:GetService("ReplicatedStorage").RemoteEvent2:FireAllClients(newTick)
return newTick
end]]
-- local script--------------
-- RemoveEvent
game:GetService("RunService").Heartbeat:Connect(function()
game:getService("ReplicatedStorage"):WaitForChild("RemoteEvent"):FireServer(tick()) end)
game:GetService("ReplicatedStorage").RemoteEvent2.OnClientEvent:Connect(function(newTick) print((tick() - newTick)) end)
-- RemoteFunction
--[[game:GetService("RunService").Heartbeat:Connect(function()
local newTick = game:GetService("ReplicatedStorage"):WaitForChild("RemoteFunction"):InvokeServer(tick())
print(tick() - newTick)
end)]]
REMOTE EVENT (PLAYER --> SERVER)
0.41117858886719
0.41526818275452
0.41310787200928
0.41574931144714
0.41620063781738
0.4141674041748
0.4126148223877
0.41458201408386
0.41301679611206
REMOTE EVENT (PLAYER --> SERVER --> PLAYER)
5.1785552501678
5.1620709896088
5.1459860801697
5.1277241706848
5.1618885993958
5.1425046920776
5.1770670413971
5.161342382431
5.1757946014404
5.1578769683838
5.1439709663391
5.1263742446899
5.1596217155457
REMOTE FUNCTION (PLAYER --> SERVER)
0.43532037734985
0.43815970420837
0.43727278709412
0.43632483482361
0.43706846237183
0.45388436317444
0.43594455718994
0.43584251403809
0.43674063682556
0.4338526725769
0.43725085258484
REMOTE FUNCTION (PLAYER --> SERVER --> PLAYER)
5.3770203590393
5.3604190349579
5.3435447216034
5.3289601802826
5.3104038238525
5.3436584472656
5.3272469043732
5.358362197876
5.3433203697205
5.3424725532532
5.3586230278015
5.342344045639
5.3255591392517
5.3616163730621
5.3441634178162
5.3611288070679
Per AggressiveCatch's suggestion, I used tick() instead of os.time() and got a much satisfying difference to see. RemoteEvents seem to be about 200 milliseconds faster, which is definitely a noticeable improvement.
Please test these differences yourself as well (and I apologize for the very messy testing code in advance!)
|
|
HenderickJoin Date: 2007-12-10
Post Count: 1523 |
Actually don't trust my results; the code is way more horribly optimized than I thought to produce reliable test results.
I shouldn't be coding at 5:30 in the morning...
I'll re-optimize the code sometime in the next 8 hours probably and run the tests again. |
|
|
"You'll run into time zone differences."
Nope, os.time is in UTC no matter what system it is called on.
From the wiki:
"This differs from tick(): tick() returns the number of seconds since the epoch from the current system time. os.time() returns this time of seconds since the UTC time, meaning that this will (theoretically) be the same on all systems. In practice, this will often differ with some seconds"
|
|
chimmihcJoin Date: 2014-09-01
Post Count: 17143 |
Read. The post. Above mine.
|
|
|
Or I could just glance at it and post something dumb again, sound k to you?
|
|
VilgOJoin Date: 2011-02-15
Post Count: 518 |
> If the developer still wants to simulate RemoteFunction behavior, he could simply use a second RemoteEvent to send the output of the first RemoveEvent to the original caller.
Or they could use RemoteFunction and not reinvent the wheel for no reason. |
|