Suppose I have 19 physics bodies in a table. I have two questions. 1) if I destroy all physics bodies does the table become empty or not? And 2) if I use this method to remove the bodies from the table, instead of “table={}” why arent all of them removed?
for i =1,#table do
table.remove(table,i)
end
Is it because when i=10 at that time and onwards there won’t be a 10th,11th… Object in the table?
for i = #tbl, 1, do
tbl[i]:destroy()
table.remove(tbl, i)
end
or, always remove the first element (this is much more inefficient):
for i = 1, #tbl do
tbl[i]:destroy()
table.remove(tbl, 1)
end
If you don’t need to explicitly destroy the bodies, then doing
tbl = {}
will probably be your best bet, unless you are doing so very frequently (due to the tables being created and GCd)
Hello @Toadkick. About table.remove(): do you know the underlying process? I mean, how the table elements are stored internally? Is it a chain of pointers, one after the other? Or a list of adress in a row? Is it cpu expensive to remove an object from a table? And how is #table updated when elements are removed?
@Jmv38: I don’t know the exact implementation details, but I believe the array part of a table stores “pointers” to each element, where the pointers are stored in contiguous memory. I say “pointers” because Lua doesn’t keep pointers to value types (numbers, booleans), so I think those types are just stored directly in the array. But really, that’s an implementation detail, and we shouldn’t be concerned about it too much…it behaves the way we would expect an array to behave, with similar performance characteristics, and that’s all that matters.
As you probably know, table.remove only works on the array portion of a table. Whenever you use it to remove an element, the elements after the removed element will be shifted down to fill the gap (just like arrays in most other languages). As such, the expense varies. Removing an element at the the beginning of an array has the potential to be very expensive, depending on how many elements you have in the array. Removing an element from the end of an array is generally not that expensive, because there are no elements after that to shift downward. However, if you have an array with many elements, this can still be more expensive than just creating a new table, simply due to the processing time it takes to iterate through the array. You don’t always have a choice though: if you have to manually destroy all of the physics bodies in an array for example, you have to iterate through the array anyway to do so, so you can just nil out your elements as you iterate.
Typically I just prefer to create a new table when I can get away with it (again, depends on the situation: I don’t want to be creating tables willy nilly if I don’t have to either, because creating tables is not cheap).
Very informative, thanks a lot!
So if i read you correctly, let’s say i want to destroy a lot of elements of a table i should start from the end, that should be faster.
Mmmm… However this bounce against another thing i thought i knew about tables: we never know what is the actual order of the elements of a table. So we cant know what are ‘the last’ elements? I think it is true for the numberred fields too (i have seen i must use for i=1,… Instead of for i,v in ipairs(… If i want to get then in the right order).
So using table.remove(…) can be 1/costly and 2/unpredictable (in cpu)…
Btw, maybe there is a link between this argumentation and another thread you are currently in about physics and reproducibility?
@Jmv38: As long as your array doesn’t have holes, you do know what the last element is: #myArray yields the last array element. Also, your info is not quite correct: ipairs() always iterates through the numbered elements sequentially, pairs() doesn’t (necessarily).
Ok. I’ll use that base, and thanks for correcting my mistake, its good to have the right picture.