Search Issue Tracker
Won't Fix
Votes
0
Found in
1.8.28
Issue ID
UUM-136293
Regression
No
Using GameObject.transformHandles is slower in Burst compared to a regular context
Steps to reproduce:
1. Open the “TransformHandlePerfBug.zip“ project
2. Open Window → General → Test Runner
3. In the Test Runner window, choose “Player“
4. Press “Run All” to run all the tests
5. Compare the difference between “SetPosition_TransformHandle(10000)“ and “SetPosition_TransformHandle_Burst(10000)“ median results
Actual result: “SetPosition_TransformHandle_Burst“ median is larger than the median of “SetPosition_TransformHandle“ (usually between 0.1-0.4 ms)
Expected result: “SetPosition_TransformHandle_Burst“ median is smaller than the median of “SetPosition_TransformHandle“
Reproducible in: 1.8.4 (6000.3.11f1), 1.8.28 (6000.3.11f1, 6000.4.0b11, 6000.5.0a8)
Could not test in: 6000.0.70f1 (Missing TransformHandle class in the Collections package)
Reproduced on: Windows 11 Pro (25H2)
Not reproduced on: No other environment tested
Note: The issue is occasionally not reproducible (if this happens, try to reproduce a few more times)
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- Texture2D hash changes inside of an AssetBundle when rebuilding a SpriteAtlas bundle with an empty AssetPostprocessor Script enabled
- Aniso Level still applies when Generate MipMap is disabled in Texture Import Settings
- Mipmap Limit Groups long names are not truncated when creating a new Mipmap Limit Group with a long name
- “ArgumentException: Invalid double parameter.” error is thrown when Infinity is typed into the Fixed Timestep field
- GameObject becomes gray when using HDRP and STP together on macOS
Resolution Note:
Hey! Thanks for reporting this bug.
I looked into this issue and found that this is actually to be expected.
The reason is that when you use TransformHandle the getters and setters for position (and the other properties) are external calls that call into the engine. These kinds of calls are not transparent to Burst at all, so they end up being barriers to optimizations, plus there's an overhead to jumping in and out of a Burst call-context (which is what's happening here).
Resolution Note:
Hey! Thanks for reporting this bug.
I looked into this issue and found that this is actually to be expected.
The reason is that when you use TransformHandle the getters and setters for position (and the other properties) are external calls that call into the engine. These kinds of calls are not transparent to Burst at all, so they end up being barriers to optimizations, plus there's an overhead to jumping in and out of a Burst call-context (which is what's happening here).