Now that may sound weird but I’ve been trying to move 5000 parts at pnce, and for some reasons in one frame BulkMoveTo is 5ms but then in the other frame when I feed it the same data (i verified part count) it appears to be 31 ms ???
now this is quite a strange behaviour, for now I thought about switching to Motor6d.Trsansform but that’s annoying as the bulk is clearly able to do less in some frames
now I’m not really sure if that’s a bug or normal behaviour or just my own cpu being weird but yeah
The performance spike happens because BulkMoveTo doesn’t always cost the same each frame even if you’re reusing the same parts. Roblox’s physics engine sometimes reprocesses movement, collisions, or replication, which randomly makes some frames heavier.
The only fix I can really think of is to make sure all moved parts are anchored, non-collidable, and call workspace:BulkMoveTo(parts, cframes)without any extra mode so it skips firing events. Or you can just do them in batches rather than such a heavy load at once, perhaps 500-1000 per call.
they already are anchored and put as can collide off and all sorts of stuff like that off
this is also literally on the client I don’t see what replication has to do with it
I’ve noticed that BulkMoveTo was actually inconsistent when resuming a script in serial sometimes half causing it to simply not work properly, there’s clearly still some work being done behind but it just didn’t update the actual parts for whatever reason thus causing the low processing time from times to times, the 32ms was the true performance, so I’ve switched to .Transform ever since and now I’m rocking 10ms for moving parts with an average of 5000 parts
