Using server-side table on client-side.

[ds1-e]

4 hours ago, IIYAMA said:

A file counts also as a function.

What about packing variables in local table? Shouldn't result be similar to define variable as local? And still it should be faster than global variable, atleast i think so. (For let you know i have small count of global variables.)

[IIYAMA]

28 minutes ago, majqq said:

What about packing variables in local table? Shouldn't result be similar to define variable as local? And still it should be faster than global variable, atleast i think so. (For let you know i have small count of global variables.)

A (local) table would probably not faster than a global variable. Because instead of doing 1 thing, you are actually doing 2 things.

1. Requesting the local variable.
2. Indexing in the table with a string.

 

That is also the reason why OOP is not very fast.

 

 

 

But as I said many times before, read-ability is also performance.

If you want performance then please consider to only apply it selective at places in the code which are used a lot. (by for example a loop or onClientRender)

 

---

 

If we look for example at the function callNextFrame: (shared: client/server)

It is very well optimised. But not 100%. What would you want to improve of this code to optimise it to a 100%?

 

local tableRemove = table.remove

local serverSide = triggerClientEvent and true or false

--[[
	-- callNextFrame function
]]
do
	
	local nextFrameCalls = {}
	
	local serverSideTimer
	

	local processing = false
	
	local function process ()
		
		--[[ 
			Do an empty check at the beginning of the function, this will make sure to make an extra run in case of heavy work load. 
			If the timer is killed or the addEventHandler is removed, then this has to be re-attached again every frame. This is not very healthy...
		]]
		
		if #nextFrameCalls == 0 then
			if serverSide then
				if serverSideTimer then
					
					if isTimer(serverSideTimer) then
						killTimer(serverSideTimer)
					end
					serverSideTimer = nil
					
				end
			else
				removeEventHandler("onClientRender", root, process)
			end
			
			processing = false
			return
		end
		
		
		-- In case of calling the function callNextFrame within the process, the loop type `repeat until` is required.
		repeat
			local item = nextFrameCalls[1]
			item.callback(unpack(item.content))
			tableRemove(nextFrameCalls, 1)
		until #nextFrameCalls == 0

	end
	
	
	
	function callNextFrame (callback, ...)
		if type(callback) == "function" then
			local newIndex = #nextFrameCalls + 1
			nextFrameCalls[newIndex] = {callback = callback, content = {...}}
			if not processing then
				if serverSide then
					serverSideTimer = setTimer(process, 50, 0)
				else
					addEventHandler("onClientRender", root, process)
				end
				processing = true
			end
			return true
		end
		return false
	end
end

 

 

This code does:

Moving a function call to the next possible frame.

 

Example:

callNextFrame(outputChatBox, "Hey next frame, I love you!")

 

 

 

 

 

 

[ds1-e]

4 hours ago, IIYAMA said:

A (local) table would probably not faster than a global variable. Because instead of doing 1 thing, you are actually doing 2 things.

1. Requesting the local variable.
2. Indexing in the table with a string.

 

That is also the reason why OOP is not very fast.

 

 

 

But as I said many times before, read-ability is also performance.

If you want performance then please consider to only apply it selective at places in the code which are used a lot. (by for example a loop or onClientRender)

 

---

 

If we look for example at the function callNextFrame: (shared: client/server)

It is very well optimised. But not 100%. What would you want to improve of this code to optimise it to a 100%?

 

local tableRemove = table.remove

local serverSide = triggerClientEvent and true or false

--[[
	-- callNextFrame function
]]
do
	
	local nextFrameCalls = {}
	
	local serverSideTimer
	

	local processing = false
	
	local function process ()
		
		--[[ 
			Do an empty check at the beginning of the function, this will make sure to make an extra run in case of heavy work load. 
			If the timer is killed or the addEventHandler is removed, then this has to be re-attached again every frame. This is not very healthy...
		]]
		
		if #nextFrameCalls == 0 then
			if serverSide then
				if serverSideTimer then
					
					if isTimer(serverSideTimer) then
						killTimer(serverSideTimer)
					end
					serverSideTimer = nil
					
				end
			else
				removeEventHandler("onClientRender", root, process)
			end
			
			processing = false
			return
		end
		
		
		-- In case of calling the function callNextFrame within the process, the loop type `repeat until` is required.
		repeat
			local item = nextFrameCalls[1]
			item.callback(unpack(item.content))
			tableRemove(nextFrameCalls, 1)
		until #nextFrameCalls == 0

	end
	
	
	
	function callNextFrame (callback, ...)
		if type(callback) == "function" then
			local newIndex = #nextFrameCalls + 1
			nextFrameCalls[newIndex] = {callback = callback, content = {...}}
			if not processing then
				if serverSide then
					serverSideTimer = setTimer(process, 50, 0)
				else
					addEventHandler("onClientRender", root, process)
				end
				processing = true
			end
			return true
		end
		return false
	end
end

 

 

This code does:

Moving a function call to the next possible frame.

 

Example:

callNextFrame(outputChatBox, "Hey next frame, I love you!")

 

 

 

 

 

 

 

But when variables are saved in local table, it's really big difference in it comparing to define variable as local?

[IIYAMA]

39 minutes ago, majqq said:

 

But when variables are saved in local table, it's really big difference in it comparing to define variable as local?

Yes, tables (and functions) are not saved in the variables.

They are objects/things that are saved at a different place in the memory. (Not that far, they are neighbours...)

The only thing that is saved in those variables are a kind of references to the thing itself.

 

Because it is not saved in to those variables directly, we are able to do this:

a = {}


b = a



a[1] = "I love it"



print(b[1]) -- I love it

 

This should really make clear that a table is not just a value, but a thing that can pretend that it exist at multiple places at the same time.

 

`a` and `b` share the same reference to the same table.

When both reference are delete, the table becomes unreachable* and the garbage collector will automatically  deal with it: http://lua-users.org/wiki/GarbageCollectionTutorial

Edited March 20, 2019 by IIYAMA

[ds1-e]

On 20/03/2019 at 18:01, IIYAMA said:

Yes, tables (and functions) are not saved in the variables.

They are objects/things that are saved at a different place in the memory. (Not that far, they are neighbours...)

The only thing that is saved in those variables are a kind of references to the thing itself.

 

Because it is not saved in to those variables directly, we are able to do this:

a = {}


b = a



a[1] = "I love it"



print(b[1]) -- I love it

 

This should really make clear that a table is not just a value, but a thing that can pretend that it exist at multiple places at the same time.

 

`a` and `b` share the same reference to the same table.

When both reference are delete, the table becomes unreachable* and the garbage collector will automatically  deal with it: http://lua-users.org/wiki/GarbageCollectionTutorial

 

What if script file will reach locals variables limit?

I saw script with 300 + local variables, and it was working well.

[IIYAMA]

19 minutes ago, majqq said:

 

What if script file will reach locals variables limit?

I saw script with 300 + local variables, and it was working well.

 

There is no limit to local variables, as long as they are used in different file or function scopes.

-- file scope 200 local's

function name ()
  -- function scope 200 local's
end

 

Edited March 22, 2019 by IIYAMA

[ds1-e]

13 minutes ago, IIYAMA said:

 

There is no limit to local variables, as long as they are used in different file or function scopes.

-- file scope 200 local's

function name ()
  -- function scope 200 local's
end

 

Ah so, functions have own limit and file have own limit, yes?

[IIYAMA]

Just now, majqq said:

Ah so, functions have own limit and file have own limit, yes?

Yes!