Relatively simple question.
I’m wondering at what point does BulkMoveTo become more performant (estimated part amount) then simply looping through parts and cframe-ing them?
(If you have no idea, please don’t reply.)
2 Likes
Probably a very low number.
To use BulkMoveTo, you need to create a partList which may only need to happen once depending on your use case, and the rest of the arguments. It likely won’t take much processing power to do these. The main advantage of BulkMoveTo is that it is handled in C++, speeding up iterations quite a bit. However, it looks really ugly and is not necessary in most cases because though the performance gain is there it still isn’t worth sacrificing your personal sanity over.
I could find a more solid number through some testing if you wanted. If you wanted that though, it’s probably better if you test it yourself.
You beat me to posting, good job. I like your data by the way, very well done.
What I was going to post:
I was curious though, and it looks like your magic number is (surprisingly to me) closer to 50. I didn’t really narrow it down since I don’t really care, but it’s likely about 40 or so.
Here are my average results from 100000 tests each.
0.00000584 seconds per 50 parts moved with BulkMoveTo
0.00000640 seconds per 50 parts moved conventionally
3 Likes
10 Likes
Make sure to also input BulkMoveMode.FireCFrame Changed into the third parameter like what @boatbomber has done with wind shake. Also perhaps BoatBomber has more insight on this topic due to well his WindShake project.
workspace:BulkMoveTo(updateObjects, cfTable, Enum.BulkMoveMode.FireCFrameChanged)
This should prevent unnecessary events from firing if I’m interpreting correctly as it only fires CFrameChanged?? documentation not very clear on this.
3 Likes
Yep, it was set to the FireCFrame property.
1 Like