Is UnreliableRemoteEvent actually that fast?

[oke60000]

Summarizing to anyone who wondering:
According to my tests and @EmmieShayz’s reply, unreliable remote events are not faster and not sends less data than default remote events. But they are useful, if you don’t much care about whether data gets delivered or not.

---

---

---

Hi devs.
In my future game i need to update Motor6D every renderstep, and i found UnreliableRemoteEvent to “don’t spend much network” on this.
But i’m very love to test everything, and before implementing it to game tested and compared it to default remote.

Results was very unexpected:

First is remote on client, second is unreliable remote on client
Third is remote on server, fourth is unreliable remote on server

Almost no difference
Sometimes unreliable remote a bit faster, sometimes default remote faster

All i found is 2 posts under unreliable remote release topic, which actually doesn’t explain anything:

Also if i look to performance stats, there’s no difference between amount sent data:

Remote

Unreliable Remote

The same happens in actual game, no difference, or tiny difference

I used this codes:
Local

local ReplicatedStorage = game.ReplicatedStorage
local UserInputService = game:GetService("UserInputService")

local Remote = ReplicatedStorage.RemoteEvent
local UnreliableRemote = ReplicatedStorage.UnreliableRemoteEvent
local CalcRemote = ReplicatedStorage.Calc

local Table = {}

local function Calc()
	local Total = 0
	for _, v in Table do
		Total += v
	end
	print(Total / #Table)
end

task.wait(3)

for i = 1, 1000 do
	local Start = tick()
	Remote:FireServer(Start)
	local End = tick()
	table.insert(Table, End-Start)
	task.wait()
end

Calc()
table.clear(Table)

for i = 1, 1000 do
	local Start = tick()
	UnreliableRemote:FireServer(Start)
	local End = tick()
	table.insert(Table, End-Start)
	task.wait()
end
Calc()

UserInputService.InputBegan:Connect(function(Key)
	if Key.KeyCode == Enum.KeyCode.U then
		CalcRemote:FireServer()
	end
end)

Server

local ReplicatedStorage = game.ReplicatedStorage

local Remote = ReplicatedStorage.RemoteEvent
local UnreliableRemote = ReplicatedStorage.UnreliableRemoteEvent
local CalcRemote = ReplicatedStorage.Calc

local Table1 = {}
local Table2 = {}

local function Calc(Table)
	local Total = 0
	for _, v in Table do
		Total += v
	end
	print(Total / #Table)
end

Remote.OnServerEvent:Connect(function(Player,Start)
	table.insert(Table1, tick() - Start)
end)

UnreliableRemote.OnServerEvent:Connect(function(Player,Start)
	table.insert(Table2, tick() - Start)
end)

CalcRemote.OnServerEvent:Connect(function()
	Calc(Table1)
	Calc(Table2)
end)

---

And also i don’t see logical difference - the same send information, the ~same ping, why there’s should be any difference?

Smart people, please explain me what i’m doing wrong.
Or these remotes doesn’t have any advantages?

[EmmieShayz (Emmie)]

There seems to be a misunderstanding - UnreliableRemoteEvents aren’t advertised or meant to be taken as “RemoteEvents but faster” - it’s more nuanced than that.

The article for UnreliableRemoteEvent states:

UnreliableRemoteEvent is best used for ephemeral events including effects that are only relevant for a short time, or for replicating continuously changing data. These events are not resent if they are lost and they do not wait for previously fired events to arrive before being processed, potentially resulting in reduced latency and network traffic. When requiring ordering and reliability, use a RemoteEvent instead.

Basically, if an oopsy happens when transmitting an UnreliableRemoteEvent request and it fails, Roblox doesn’t do anything to resend it, which, in the case of continously updating data, means that there isn’t any unnecessary traffic spent replicating a value which is no longer relevant.

Also - from your test it seems that you are measuring the time it takes to fire a request on the client and the time it takes for the request to arrive on the server as benchmarks. You are essentially just measuring ping, and this is going to be minimally different if there’s no packet loss.

[oke60000]

Oh, thank you. I’m definitely blind if i didn’t noticed this line in documentation.

@EmmieShayz

You are essentially just measuring ping, and this is going to be minimally different if there’s no packet loss.

Yes, i know, and i wrote about this.

I’ll leave this topic open for a few days, maybe someone reply here something new. (I’ll mark your post as solution after this)

Thank you again