Creating a LOT parts causes lag spike

[ZINTICK]

You must be reading the title and like no way dude!

But the issue is that I have a simple map generation system. And this generation system is pretty alright. However making these parts spikes receive. Which causes lag on some devices. How can I get rid of this lag when making many parts at once?

[Minstrix]

How many parts are we talking? In general, creating a “LOT” of instances is going to be expensive, but there are a few things you could do to optimize it:

1. Set properties before setting the parent (e.g. set size, color, etc, before you put it in the workspace)
2. Set position and rotation on all the parts at once via workspace:BulkMoveTo()
3. If your system destroys parts before generating new ones, try reusing the parts instead (by updating their properties) to avoid unnecessary :Destroy() and Instance.new("Part") calls
4. If all else fails, spread the work out over multiple frames! If your system generates each part in a loop, add something along the lines of if i % 100 == 0 then task.wait() end and then your system will “yield” every 100 parts so that a new frame can be rendered before continuing.

I think in your case, #4 is probably going to be the key. Good luck and let me know how it goes!

[ZINTICK]

I think number 2 is exactly what I need and maybe even number 1. But I don’t understand exactly how to use bulkmoveto and the documentation confuses me

[TheGrimDeathZombie (Reapimus)]

Here’s a more visual example of BulkMoveTo that should help in understanding how it works. It’s pretty much as simple as the method will move each part in the first argument to the corresponding CFrame that is at the same position as it in the second argument:

local PartA, PartB = path.to.partA, path.to.partB
local TargetA, TargetB = CFrame.new(), CFrame.new()

workspace:BulkMoveTo({PartA, PartB}, {TargetA, TargetB})
-- This will move PartA to TargetA, and PartB to TargetB, because TargetA is at the same index as PartA and TargetB is at the same index as PartB.