Tables and performance

[pro_developer213]

hi, im new at tables so idk but people say to many tables is lagy, i have some questions:

what is more lagy,

local Table = {}

or

local Table = table.create('eg')

and how to use table.create()?

and what is more good to use:

for i, v in next, game.Player:GetPlayers() do

or

for i,v in pairs(game.Players:GetPlayers()) do

please i need to know so my Custom DataStore sitem to not be so lagy

[Rare_tendo]

table.create does not exist - it’s totally unnecessary because there’s already a way to construct tables.

As for your next question, this thread will help
https://devforum.roblox.com/t/solfed-next-vs-pairs-vs-numeric-for/17369

[pro_developer213]

oh so next is equal to pairs but ipairs are faster?

[DrKittyWaffles (x64dbg)]

@Raretendoblox

table.create does not exist

table.create actually does exist. There is valid use cases for a table.create It is not “unnecessary”

Release Notes for 407

[image] I feel like table.create is going to be underrated, but that update looks amazing. I assume that the memory allocation is done on the backend instead of whenever you create a table? To get around this, I currently construct tables with placeholder values or initialise members with placeholders. -- Construction with a size of 8 local array = {1, 1, 1, 1, 1, 1, 1, 1} -- Construction with members local dictionary = { Test = 1, Other = 1, } Does table.create work in around the s…

Faster Lua VM: Studio beta

When adding to tables without table.create, Lua will often allocate more memory than needed (because it allocates in powers of two.) In most cases I just want to save a bit of memory. This isn’t a bottleneck in the same way table searching is, but I’ll search my codebase and give a few examples: Creating nested tables of arbitrary size for use with terrain:WriteVoxels() I have a list of parts, and now to build the object later I need to store a corresponding list of cframe offsets. I now wa…

Images

As for next vs pairs I suggest using pairs for the fact that it is idiomatically similar to other functions employed in lua such as gmatch

[ReturnedTrue (Tr_uth)]

pairs behind the scenes is basically:

local function pairs(tbl)
    return next, tbl, nil
end

There won’t be much difference here.

However, if you’re iterating through arrays then I’d recommend using ipairs as recently in the new VM it has been optimised & it promises ordered iteration.

[Autterfly]

The new compiler employs idiomatic optimizations so that for i, v in pairs is no longer its equivalent function call wrapper, so it’s not exactly the same anymore, but since next has also been added to the list of optimizations they’ll still be about the same speed.

[Tomarty]

@EpicMetatableMoment

As for next vs pairs I suggest using pairs for the fact that it is idiomatically similar to other functions employed in lua such as gmatch

While pairs will work, ipairs is intended for arrays and will likely run a bit faster in those cases. Iteration order is also not necessarily predictable when using pairs/next, while ipairs will always start at 1 and stop at the first nil/hole in the array.