Are Frozen SharedTable Reads Faster Than Standard SharedTable Reads?

Help and Feedback Scripting Support
1

I want to know weather a read operation performed on a frozen SharedTable is faster than the same read operation performed on a standard, non frozen SharedTable or not?

I tried to benchmark the read times, but with these results, I do not know whether the difference is simply that small or if there is no actual difference and what I’m seeing as difference is simply just noise.

--!optimize 2

-- Create 2 Identical SharedTables With One Array And One Hash Part, One Frozen, one not Frozen.
local Warmth_Shared_Table: SharedTable = SharedTable.new({[1] = 1, Hi = "Hi"})
local Frozen_Shared_Table: SharedTable = SharedTable.cloneAndFreeze(Warmth_Shared_Table)

local Time: number = 0						-- TValue To Handle Time
local Iterations: number = 1e7				-- Benchmarking Sample Size
local Value: number? | string? = nil		-- TValue To Store Results In

-- Cache os.clock So That Calling Clock Just Loads A Register Instead Of A GETIMPORT or a GETUPVAL +
-- GETTABLEKS instructions, Reducing Chances Of Error.
local Clock: typeof(os.clock) = os.clock

task.wait(30)	-- Wait For CoreScripts To Setup.

Time = Clock()
for Key: number = 1, Iterations do Value = Warmth_Shared_Table[1] end
Time = Clock() - Time
print(`Warmth Number: {Time / Iterations}`)

Time = Clock()
for Key: number = 1, Iterations do Value = Frozen_Shared_Table[1] end
Time = Clock() - Time
print(`Frozen Number: {Time / Iterations}`)

Time = Clock()
for Key: number = 1, Iterations do Value = Warmth_Shared_Table.Hi end
Time = Clock() - Time
print(`Warmth String: {Time / Iterations}`)

Time = Clock()
for Key: number = 1, Iterations do Value = Frozen_Shared_Table.Hi end
Time = Clock() - Time
print(`Frozen String: {Time / Iterations}`)

Result:

  11:15:14.354  Warmth Number: 1.4017838000145274e-07  -  Server - Script:20
  11:15:15.717  Frozen Number: 1.3632349999970757e-07  -  Studio
  11:15:17.379  Warmth String: 1.6611362000112422e-07  -  Studio
  11:15:18.980  Frozen String: 1.6006959999795072e-07  -  Server - Script:35

Now I do not know if this 4 - 6 nanosecond difference is the difference in read speeds or just due to noise

If anyone knows about it, please let me know! Thanks!

2 Likes
2

Its most likely just a noise because its different each time i run it
Cannot be sure because implementation of it is opaque
Either that or its CPU dependent
The only reason you want to freeze table is for parallel luau anyway
image

2 Likes
3

Yeah, parallel luau is exactly what I want to do. I am working on a codebase of sorts based on Data Oriented Design where I put the data of modules shared across Actors into a SharedTable which is then read by module used across multiple actors. However, as is the case with SharedTables, the reads are ~10x slower than a luau table read (in fact, SharedTable reads are on same level of time-taken as Instance property reads), so I was wondering if I can make a Feature Request asking the engineers to fast path reads on frozen sharedtables to bypass using the std::mutex entirely.

4

What happens if you benchmark with native

5

I tried benchmarking with native, while it certainly widened the gap, it is still barely noticable, with this small of a difference I believe we can safely consider that the Frozen SharedTable reads are, in fact, at same speed as Standard SharedTable reads.

  10:11:31.549  Warmth Number: 1.893099799999618e-07  -  Server - Script:21
  10:11:33.142  Frozen Number: 1.5925217000003614e-07  -  Server - Script:26
  10:11:35.112  Warmth String: 1.9697180000002844e-07  -  Server - Script:31
  10:11:36.982  Frozen String: 1.8705589999999575e-07  -  Server - Script:36
1 Like