Roblox LuaBridge - Where the magic lies within when talking to the DataModel!

[HealthyKarl]

I don’t think Luau and C++ are in the same environment. Especially the Roblox Engine. Instead things have to communicate with eachother. Based on my observation, LuaBridge is responsible for it.

The LuaBridge is an important secret crucial component. Understanding it can be key if you want to develop something that is equavilient to the next generation of CPUs on Roblox.

 

If I access TestPart.Color

Within the MicroProfiler, you’ll find it as index_Color.

And before I accessed that I accessed game.Workspace.TestPart which are more LuaBridge invocations.

 

It should make sense that if you call something like this

Expand

-- Let's assume thus were LuaBridge related things
tbl
tbl.tbl1
tbl.tbl1.tbl2
tbl.tbl1
tbl

That it’s gonna take longer.

compared to this

Expand

-- Let's assume thus were LuaBridge related things
local tbl = tbl
local tbl1 = tbl.tbl1
local tbl2 = tbl.tbl1.tbl2
tbl1
tbl

Now, Luau might do optimizations on its own, so take what I say very roughly.

 

Actually it seems to do something.

 

This leaves us with interesting questions.

Why does it take less longer the second time I index .Color?

Well, not so sure, but here are some rough theories that I took with the MicroProfiler.

I think that LuaBridge allocates something temporarily. These things may be important for RenderStepped. BindToRenderStep is better, because you can adjust the priority, which makes a very big difference, I think.

Theories

I called the same index, on a ModuelScript and it the 1st call also took longer compared to the 2nd.

 

I believe that there’s something special where it keeps certain information at.

If I add a task.wait(5) inbetween both of my profilings, I am resetting the LuaBridge?

 

I believe that LuaBridge somehow does its own magic to make things faster

 

So, I tried a BindableEvent

If I add a print inbetween, the next .Color indexing would take a tiny bit longer.

I can’t really tell…

What I can tell is that if it’s within one shot, the next indexes should take less time.

So, not using print inbetween my tests = better results

 

What does this mean?

If you are using Instances for your main source of data, e.g. BoolValue and etc. that you’re somehow using with .Value all the times, maybe you want to cache it into Lua with something like .Changed?

I don’t know how fast it is within Luau. But if they created something called LuaBridge, I can imagine that Luau is faster than the LuaBridge, otherwise they’d have named it LuaLightningSpeedBridge.

and instead of doing game.Workspace.TestPart do

local TestPart = game.Workspace.TestPart and then use TestPart within expensive function calls.

Caching is memory though, so you have to think.
Not that much of memory though.

[towerscripter1386 (Tower)]

I think bytecode compiler automatically inline such:
game.Workspace.SomePart

Though it only does so in game or if you do:
--!optimize 2

Still useful if you create stuff at runtime since bytecode compiler can’t inline anything at runtime

[TheRealANDRO (ANDRO)]

@HealthyKarl

Why does it take less longer the second time I index .Color?

Using local increases performance due to how Luau statements are handled internally.

Take this example:
a = a + b

a is a global variable. And this statement generates this input internally:
(may not be accurate in Luau, there might be more optimizations, but this is how it’s generally done in Lua internally.)

GETGLOBAL 0 0 ; a
GETGLOBAL 1 1 ; b
ADD 0 0 1
SETGLOBAL 0 0 ; a

Whereas when you use locals, it only generates this:

ADD 0 0 1

The same is likely true for indexing Instances. Using local caches the reference to the Instance internally, so the same reference gets used every time, whereas global accessing either causes that reference to change or internal systems take longer steps like above to reach that reference.

Either way, you should use locals. They’re much better and faster, and allow you to handle scopes better. And LuaBridge might be related to how Instances and their references are handled within the Engine.