Search Issue Tracker

Active

Under Consideration for 6000.5.X

Votes

9

Found in

6000.0.59f1

6000.2.7f1

6000.3.0b4

6000.4.0a1

6000.5.0a1

Issue ID

UUM-121642

Regression

No

Object.Destroy takes unreasonably long when called on large prefabs

Scripting Runtime

-

How to reproduce:
1. Open the "UnityBug_DestroySlow.zip" project
2. Build and run the project
3. Open the Profiler
4. Record the Player
5. Wait for a few minutes and record until the Rendering section graph lines have stopped dropping down
6. Stop recording
7. Search the Profiler Hierarchy by the keyword "Destroy"
8. Search through the profiler for "Destroy" calls and observe their "Time ms"

Actual results: Most Destroy calls are in the range 10-30ms
Expected results: Most Destroy calls are <1ms, and rarely climb to 5ms

Reproducible in: 2022.3.71f1, 6000.0.67f1, 6000.3.7f1, 6000.4.0b7, 6000.5.0a6
Could not test in: 2023.1.0a1 (integral InstantiateAsync for the reproduction not introduced), 2023.3.0a19 (the project crashes when building the Player)

Reproduced on: Windows 11 Pro (25H2)
Not reproduced on: No other environment tested

Notes:
- Currently 'parallel_count' is set to 4, however The Destroy calls are more severe if the variable 'parallel_count' value is changed to 16 in the "BugReportScript (2).cs" Script (takes longer to reproduce)
- The reproduction and CPU usage spikes become more consistent and severe after waiting for the second or third wave of the Rendering graph lines dropping
- Sometimes long Destroy calls can be observed before or after the drop in the Rendering graph (or even when the lines are rising), but it is much more consistent to profile during the dropping phase

Comments (3)

  1. funkyCoty

    Jan 29, 2026 23:25

    Still an issue on Unity 6.5a5,

  2. CorgiCoty

    Jan 24, 2026 06:29

    We would love to see this fixed!!! 🙏🙏🙏🙏🙏

Add comment

Log in to post comment

All about bugs

View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.