Nested tables and performance (SOLVED)

Questions
1

In the game I’m working on I’m using tables to store information about my peeps (and also other stuff in a similar manner) like this:

peep.work = {}
peep.hunger = {}
peep.fatigue = {}
peep.location = {}
peep.money = {}
peep.action = {}

etc…

So that for example peep.money[k] gives me the current money of the peep with a unique ID k.

Well, it dawned on me that I’m using a group of tables contained in a larger table, which I’m not really using for anything. I could easily dispense with the whole “peep.” part and just have tables called work, hunger, fatigue etc. and I shouldn’t lose any functionality.

It’s ok. I’m treating this as a learning exercise and writing the code like this helped me conceptualize the whole thing in my head.

My question is whether I should simplify the code by removing the overreaching “peep” table because it’s either somewhat less efficient or simply bad coding practice, or if it’s fine to leave it the way it is. I’m mostly concerned about a part of code where I’m iterating based on peep.action (allowing me to update each peep) which is repeated every “turn”. I’m trying to keep that part as fast as possible, as it can add up.

Thanks!

1 Like
2

I doubt you will win anything by removing the container table. If you have lots of peeps and iterate over each one often you might want to think about ways to iterate over fewer peeps (by culling, partitioning etc). This may lead you to a different data structure though.

4 Likes
3

Good to hear. I’m thinking of some way of taking some of the peeps (who are busy with some activity and won’t have to make any decisions for some specific time) out of the pool that gets iterated every time, but I think I can easily deal with that later. Removing the container table is only going to become more difficult with time, so I wanted to make sure it’s not costing me anything while the code is still relatively simple.

Thanks for alleviating my fears!