Most Performant Way to Access ModuleScript Tables

I’m creating a module to hold data for ~2000 entities at a time.
This could be position, inventories, health, etc.
There’s going to be a lot of data flying around, so I’m trying to find the best way of accessing/setting it.
ps. I’m optimising the hell out of this, hence the question:

Is it better to have a function inside the modulescript to get/set data in a module script, versus making the table accessable to other scripts and doing it from them?


-- ModuleScript
local Entities = {}
function module.Get(key)
    return Entities[key]
-- Another Script
local entity = ModuleScript.Get(1)


-- ModuleScript
module.Entities = {} 
-- Another Script
local entity = ModuleScript.Entities[1]


I’m aware of how ModuleScripts work, but not of their low level performance caveats.
Please don’t explain how ModuleScripts work :stuck_out_tongue:

Well, not talking from experience, but I would suppose that accessing the data directly would be faster than using a function to do the same, though I am not sure.

Keep in mind that to do that you need to call a function, index a table, and return the value.
As opposed to simply indexing it.
Edit: Thanks for your input! :>

Well, yes. But only one time.

If each entity’s data is only going to be “gotten” once, then the difference in terms of performance is negligible.

However, if you are calling :Get many many times over and over, it could be slower.

Once again, I have not tested it, just going off the top of my head.

Dictionaries are great for dealing with a bunch of key-pair values that are unsorted, that’s why they’re used when storing data. It is easier to just use the player’s unique id to index a specific entry rather than iterating through an entire array and checking each entry for a match.

local dictionary = {}
--// I care about the keys so I use a dictionary
dictionary[13212721] = {Money = 32, Health = 100}
dictionary[21251241] = {Money = 51, 100}

Arrays are great when you want to have some data that needs to be grouped and sorted. For example say you have an array of greetings and when a player enters the game you want to choose a random greeting.
You don’t really care about individual greetings because they don’t have any unique properties. You would just generate a random number based on the array’s length and use that to index your greetings array.

local greetings = {"Hi!", "Hello!", "Welcome!"}
--// I don't care about the keys so I use an array
local myGreeting = greetings[math.random(#greetings)]

Also, don’t worry too much about optimization because premature optimization is the root of all evil.

1 Like

The second approach, where the Entities table is just returned by the ModuleScript, is the more performant approach. The first one adds an extra function call and isn’t required for your usage.

It is worth mentioning however that it’s an INCREDIBLY minor difference in terms of speed, so you’ll most likely never end up reaching a point where performance would be impacted by it. We’re talking hundreds or thousands of calls per second to see any sort of difference, and even that’s at a push.

In short, the second approach is the fastest but the performance gain is very much negligible for 99% of cases where you’d use it.


Hi, sorry for the delayed response.
I’ll be using arrays nested dictionaries.
The order of keys in the uppermost dict is not consistant. Example:

local Entities = {
    [1] = {},
    [3] = {},
    [10] = {}

I’m aware of the performance drag of hash tables, but shifting around keys ain’t possible :confused:
Do you know if Luau caches the result of hash keys?
Thanks dude!

ps. Generally I’d agree premature optimisation is a poor idea, but this system will be working on an enormous scale [possibly 2000 requests a second].

Thanks! <3
My dreams of making an ARK “”“inspired”"" game will be pushing roblox servers to their limit >:) I’m just tryna optimise the best I can!

1 Like

As in, hash each key and store that?

If so, then yes.

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.