I am not good using tables, how would i add all the things in workspace to it like this?
local table1 = {}
local table1 = {}
for _, v in pairs(workspace:GetChildren()) do
table.insert(table1, v)
end
That should work 
For more information you should visit the table documentation.
2 Likes
better yet,
local table1 = workspace:getChildren()
EDIT: I guess I should explain this.
The Instance:GetChildren() method returns a table containing all of the children, or immediate descendants, of the instance. Therefore, you can set your table equal to workspace:GetChildren(), and then boom, there’s your table, no for loop required.
3 Likes
???
This text will be blurred
My bad, I should have explained it better. I edited it for clarity. Lmk if you have any questions 
But what would be better then? (In optimization)
At the end of the day this change is going to be micro-optimization and outside of less than a fraction of a second isn’t going to really hold much immediate value in changing. Mostly because after all is said and all is done both arrays will be taking up the same amount of memory.
If you’re actually worried about micro-optimizing code that much- you might as well use ipairs instead of pairs because GetChildren returns a simple array.
You can use either of these methods.
1 Like
In terms of optimization, as @SummerEquinox stated, either method will do you just fine unless you really need to shave off those milliseconds.
I simply stated my solution as a more concise way to get the table.
Details for if you do *really* need to shave off those milliseconds
Using this method:
local table1 = workspace:GetChildren()
would be faster than using this method:
local table1 = {}
for _, v in pairs(workspace:GetChildren()) do
table.insert(table1, v)
end
This is because in both instances, the :GetChildren() method is called, so we have to look at what else is happening.
For the first method, the script must run the method :GetChildren(), and store the result as table1.
For the second method, the script must create a new table and store it as table1, run the :GetChildren() method, loop through every value of the table, and then insert the value into the table. Please note that performing a function for every value of a table can take a bit of time if the table is large. In this case, that means that if workspace has a lot of children, it may take a lot longer than it should to complete the function.
In the first method, the script has to do less stuff, which in most cases and certainly in this case, will end up causing this method to be faster.
Conclusion: local table = workspace:GetChildren() is faster, especially if you have a lot of items in the workspace.
Why I would argue for the use of my method over the for loop method
I would argue for the use of my method over the other method because :GetChildren() simply returns a table. We can substitute workspace:GetChildren() with some table to see clearer what’s really going on.
My method, workspace:GetChildren() substituted with {1, 2, 3}:
local table1 = {1, 2, 3}
For loop method, workspace:GetChildren() substituted with {1, 2, 3}:
local table1 = {}
for _, v in pairs({1, 2, 3}) do
table.insert(table1, v)
end
It’s much easier, much more concise, much more readable, and much more computational-cost-efficient to simply declare table1 and assign its value as {1, 2, 3} instead of declaring table1, assigning an empty table to it, and inserting the values of the table {1, 2, 3} one by one into table1, which is what the for loop method does.
In the same way, we can simply declare table1 and assign its value as workspace:GetChildren(), which returns a table, instead of declaring table1, assigning an empty table to it, and inserting the values of workspace:GetChildren() one by one into table1
Conclusion: assigning workspace:GetChildren() to table1 upon declaration is more concise, straight-forward, readable, and efficient than using the for loop.
I hope this helps 
EDIT: Even though I have suggested one method, you are still free to use the other method if you like. Neither method is incorrect. I would assert that the only incorrect solutions to a scripting problem would be solutions that don’t actually solve the problem. Both methods end up with you having a table with all of the children in workspace, so, if you prefer the other method over the one I have suggested, then use it.
1 Like
I’ll add onto this for further clarity. The most important factor is going to be readability. The rest isn’t really worth understanding as a beginner in my opinion.
Premature optimization is not a good practice to adopt. That said, this isn’t really premature optimization. It’s just removing redundant code. I’ll write this next part under a section, because I’m not sure how much I’ll end up writing.
Open more...
local mySet = {}
local mySet2
local clock
local clock2
task.defer(function()
clock = os.clock()
print("CHUNK 1: Starting...")
for _,c in ipairs(workspace:GetChildren()) do
table.insert(mySet, c)
end
warn("CHUNK 1: "..os.clock()-clock)
end)
task.defer(function()
clock2 = os.clock()
print("CHUNK 2: Starting...")
mySet2 = workspace:GetChildren()
warn("CHUNK 2: "..os.clock()-clock2)
end)
21:43:16.427 CHUNK 1: Starting... - Server - Script:9
21:43:16.427 CHUNK 1: 0.00018700002692639828 - Server - Script:14
21:43:16.427 CHUNK 2: Starting... - Server - Script:19
21:43:16.427 CHUNK 2: 0.00006370001938194036 - Server - Script:22
Keep in mind that both chunks begin at the same time.
There will almost always be a fractional difference between these two. The more instances which exist in workspace, the more the impact will scale.
Okay, so there’s a negligible performance difference. Why is the code redundant? Explorer objects are always going to exist under Roblox’s base class called instance. GetChildren is a method that exists about this base class. This means that every service you access, including workspace, has access to the GetChildren method through inheritance no matter where it is located inside of the game, so long as it exists under some accessible environment.
Because it isn’t open-sourced, but also more likely because it may be wrote in C, we might struggle to compare the two. GetChildren as a method likely just does exactly what the first option would do if GetChildren didn’t exist. It probably uses self (or its C equivalent) to access each child object in its hierarchy one at a time placing them into an accessible array, and then the function would return that array.
Given that understanding of GetChildren, when we look at the first option we can immediately recognize that the exact same code chunk is occuring twice when it only needs to happen once.
The impact will be negligible, but ultimately only scalable to a certain extent.
1 Like