Lua 5.4 performance (issues or just potato?)

Edit: Dbub pushed several improvements - many thanks

Not sure if this constitutes a bug so I thought it would be best to get some more information here. Apologising in advance.

I’m still new to coding and, aside from very limited JS experience, have only used cfxlua.
I looked through gottfried’s lua fork and really liked what I saw, on top of reading through the 5.4 reference manual.

From what I’ve seen it should perform faster, but it seems like there may be problems? Until I’m performing a lot of actions every tick, resource usage is higher.

Information

I’ve been checking performance every now and then for around a month, with both canary and production builds. I use the recommended server artifact, so right now 4394. Home hosted using Windows, tested with essentially no resources enabled.

Empty lua file

Memory improvements aside, the server uses slightly less CPU and the client uses more (yes I realise how negligible this is). I’ll include some more screenshots and code below.

Empty threads

CreateThread(function()
	while true do
		Wait(0)
	end
end)

for i=1, 20 do
	CreateThread(function()
		while true do Wait(0) end
	end)
end

Iterator

CreateThread(function()
	while true do
		Wait(0)
		for i=1, 10000 do
			local var = var
		end
	end
end)

Once we’re actually doing a lot with those threads we actually start to see improvements, but nobody needs to iterate 10,000 times per tick.

Playing with different numbers, it wasn’t until around 550 iterations that 5.4 started to get ahead on both client and server.



If you’re making a resource with no, or very slow, threads then the benefits will definitely start to show, otherwise you can make large single-resource servers to maximise the benefits but then you’re better off using JS/TS.

I considered a “thread manager” resource and exporting everything I want to run on an interval to that to create supersized-threads but I don’t know if that would cause hell to break loose.

3 Likes

Here’s server on this end with LUA_CPP_EXCEPTIONS removed:

image

It seems this little flow change does indeed slightly affect yield performance.

2 Likes

Another fun comparison with some extra fixes forward-ported (disclaimer: the string return is just nil as I didn’t have a player connected in slot 1):

for i=1, 200 do
	CreateThread(function()
		while true do Wait(0); for j=1,50 do GetPlayerEndpoint(1) end end
	end)
end

-oal is with use_fxv2_oal enabled, which makes for much faster invocation of native functions, at the expense of removing certain tricks like Lua __data fields or automatic vector expansion.

3 Likes

In addition to that, here’s a less contrived OAL comparison between Lua versions and JS:

CreateThread(function()
	while true do Wait(0); for j=1,50 do GetPlayerEndpoint(1) end end
end)
setTick(() => {
	for (let i = 0; i < 50; i++) {
		GetPlayerEndpoint(1);
	}
});

image

Both the V8 C++ API being slow as well as there being no OAL equivalent for the JS ScRT hit hard in this fight.

I’ve intentionally not included C# as the fast-path for native invocation on there is client-only due to some Mono bugs on Linux, but historically it has been faster at native invocation benchmarks - running 20000 natives a frame - than non-OAL Lua.

5 Likes

Should be merged in now, though a more proper changeset may be pending.

4 Likes

A surprise to be sure, but a welcome one. Thanks for putting your time into this :pray:

3 Likes

200

1 Like