Start with a Player build
Measure on the hardware you want to support. Scene view, the Profiler and other Editor windows add their own work, so an Editor frame time is not your game's final frame time.
Group edits into a batch
Wrap related placements in VegetationAPI.BeginRuntimeBatch(area). The records change immediately and the batch queues their render updates together. Dispose the batch in the same frame; do not keep it open across a coroutine yield or await.
Place several plants
using (VegetationAPI.BeginRuntimeBatch(area))
{
VegetationAPI.Place(area, new Vector2(2, 3), 0, seed: 10);
VegetationAPI.Place(area, new Vector2(3, 3), 0, seed: 11);
}Prepare space during loading
For predictable edits, reserve source cells with PrepareRuntimeCapacity, render packets and GPU space with PrepareRuntimePageCapacity, and sorting proxies with PrepareRuntimeProxyCapacity. Include plants already in the region, the edits you expect, and space for the old and replacement render fronts.
Preparation copies or allocates memory and can take noticeable time in a dense scene. Do it during loading. Use requirePreparedCapacity when placing or moving an instance if you want the API to reject an edit that would exceed the reservation. Ordinary placement APIs can grow their storage.
Measure when the change becomes visible
The API's edit time and the time until the camera displays it are different measurements. Render updates are spread across frames; the previous complete vegetation remains visible while the replacement is built. A 5,000-plant edit may need several frames even when the placement call is quick.
Find the expensive part
- CPU: check large edit bursts, unprepared capacity, streaming and sorting work.
- GPU: check overlapping transparent sprites, shadows, screen coverage and material variety.
- Saving: saving plant placements or clicking Save Backup can take time in a large world. Do this at a checkpoint or when the user clicks Save, not every frame. Play Mode saves do not make backups.