Noticeable difference in latency between Remote Events and Functions

Hey, so I’ve been working on an attack system, and originally I used a RemoteEvent to communicate with the server to handle one aspect of the system (Raycasting). However, I decided to switch to a RemoteFunction since I needed the ability to have a response sent back! There seems to be a noticeable delay between the RemoteFunctions and the RemoteEvents.

I’m assuming this is due to the client needing to wait for a response from the RemoteFunction.

Has anyone else experienced this, if so, how could I fix this, or even shorten the latency?

Did you run a benchmark to compare the two?

It would make sense for RemoteFunctions to take longer, due to the fact they’re invoked to the server from the client, so that takes time, and then after the server receives the invoke, it’ll send the response back to the client, and while all this is happening the current thread on the client that’s running the code is yielding for the response.

A possible solution here is to manage the asynchronous code so that it doesn’t interfere with your other tasks. Perhaps using promises and assigning callbacks for when ever the request is received.

I didn’t end up running a benchmark, since the difference is quite noticeable.

But sure, I’ll go ahead and try to make it so it doesn’t interfere with my other tasks.

Something I’ve recently implemented was an approach more like:

getDataRemote:FireServer()

getDataRemote.OnClientEvent:Connect(function(data)
--//data is received, and handled as an event to not interfere with other tasks

--//execute necessary code when ever data is received
end)

This was a solution I was pondering on. However, the rest of the code requires that the value returned from the RF is present.

Are there any solutions that adapt around this circumstance?

You could modify your design so the necessary callbacks are executed each time the data is received, I tried to add some notes in my pseudocode above.

You could also cache the value(s) passed to the client as variables so it becomes accessible to other scopes in your code as well.

Good point. I’ll probably modify my design, rather than caching here, since the value returned is new each time. Thanks for your help!

1 Like