[Lua] Structured Tables

[coffee]

Since I was revising the way of structure my table data, I did some googling and found this interesting comment and respective answer
http://www.learn-corona.com/2010/10/an- ... comment-12
I like very structured tables, it feels "natural" organizing in this way. Do someone use this deeper hierarchical tree data storage? It's efficient enough like he asks?

Supposing you have to use a container for hosting in-play data, which may be accessed (with get/set functions) at every frame in a game, how would you construct a Lua table to do this efficiently?

Flat Solution:
data={
opponents=2
anger=5
bonuses=6
hits=0
lives=3
energy=10
…
}

Structured Solution:
data={
scene={
bonuses=6,
enemies={
opponents=2
anger=5
}
},
player={
hits=0
lives=3
energy=10
}
}

I find the second way more convenient, but, from your experience with Lua, is deep-level table indexing (x=data.scene.enemies.anger) efficient enough, performance wise, for use in Update() calls?

and also I'd love to know if as in the poster answer you usually use or think it's a good "shortcutting/indexing" method:

data = {2, 5, 6, 0, 3, 10}

-- assign the indices to variables (if possible, use local variables)
opponents = 1
anger = 2
bonuses = 3
hits = 4
lives = 5
energy = 6

-- examples:
myBonuses = data[bonuses]
myEnergy = data[energy]

Thank you in advance for your thoughts!

[Robin]

I like very structured tables, it feels "natural" organizing in this way.

Then do it. It's very efficient in Lua.

That "shortcut" you mention at the end is horrible, please don't use it!

[nevon]

That "shortcut" you mention at the end is horrible, please don't use it!

Why is that? I thought it would be more efficient if you're doing it in a loop, for example, to save lookups.

[Robin]

That "shortcut" you mention at the end is horrible, please don't use it!

Why is that? I thought it would be more efficient if you're doing it in a loop, for example, to save lookups.

First of all, t.foo is more efficient than t["foo"], due to how Lua works, but much worse: if use a sequence as an object, you lose all semantic information that you would have with string keys. Plus in this case the variables are all global, which makes it even worse.

[nevon]

That "shortcut" you mention at the end is horrible, please don't use it!

Why is that? I thought it would be more efficient if you're doing it in a loop, for example, to save lookups.

First of all, t.foo is more efficient than t["foo"], due to how Lua works, but much worse: if use a sequence as an object, you lose all semantic information that you would have with string keys. Plus in this case the variables are all global, which makes it even worse.

Ah, then I understand what you mean, and in that case I agree. I was thinking more of using it as a local variable inside a function to save lookups in a loop. Sure, it's completely unnecessary performance wise, but it could be nice to have to type less.

[Robin]

Well, yeah, and it could even make the code more readable if done properly, which I'm all for.

[coffee]

I like very structured tables, it feels "natural" organizing in this way.

Then do it. It's very efficient in Lua.

That "shortcut" you mention at the end is horrible, please don't use it!

Thank you for the encouragement. I already converted map tables in some something more hierarchical envolving layers, tile objects and other map information. Until now no performance loss. Character data is also being revised. And I will try later a total fusion of all game data.

[Xgoff]

First of all, t.foo is more efficient than t["foo"], due to how Lua works

wat. they're the exact same thing

t3d0S.png (39.55 KiB) Viewed 442 times

[Robin]

My bad, I thought Lua optimised dot access. I guess it's still better than t[foo], though, if foo is a global.

Code: Select all

~$ luac -l -p -
return t["foo"]

main <stdin:0,0> (4 instructions, 16 bytes at 0xa75230)
0+ params, 2 slots, 0 upvalues, 0 locals, 2 constants, 0 functions
	1	[1]	GETGLOBAL	0 -1	; t
	2	[1]	GETTABLE 	0 0 -2	; "foo"
	3	[1]	RETURN   	0 2
	4	[1]	RETURN   	0 1
~$ luac -l -p -
return t[foo]

main <stdin:0,0> (5 instructions, 20 bytes at 0x1929230)
0+ params, 2 slots, 0 upvalues, 0 locals, 2 constants, 0 functions
	1	[1]	GETGLOBAL	0 -1	; t
	2	[1]	GETGLOBAL	1 -2	; foo
	3	[1]	GETTABLE 	0 0 1
	4	[1]	RETURN   	0 2
	5	[1]	RETURN   	0 1
~$ luac -l -p -
local foo; return t[foo]

main <stdin:0,0> (4 instructions, 16 bytes at 0x159b230)
0+ params, 2 slots, 0 upvalues, 1 local, 1 constant, 0 functions
	1	[1]	GETGLOBAL	1 -1	; t
	2	[1]	GETTABLE 	1 1 0
	3	[1]	RETURN   	1 2
	4	[1]	RETURN   	0 1

[coffee]

My bad, I thought Lua optimised dot access. I guess it's still better than t[foo], though, if foo is a global.

So, in pratical terms whatever the method chosen the performances variations are unnoticeable?