Search Issue Tracker

Won't Fix

Votes

0

Found in

6000.0.35f1

6000.1.0b3

Issue ID

UUM-95363

Regression

No

Huge performance overheads appear when there is a large amount of bindings in the UI Toolkit

-

Reproduction steps:
1. Open the attached “repro_IN-90324“ project
2. In the Editor menu, select “BugReport → Bind Test Window“ and snap it somewhere (for example, near your Scene tab)
3. Open the Profiler (“Window → Analysis → Profiler“) and snap it on top of the “Bind Test Window“ so it’s not visible
4. In the Profiler, in the “Target Selection“ dropdown, change to “Edit Mode“
5. Enable the “Deep Profile“ selection
6. Press “Record profiling information“ or simply press “F9” on your keyboard
7. Don’t move your mouse for a while and observe the graph in the “CPU Usage“ section
8. Notice that the performance stays around 0.25 ms (could vary depending on the machine)
9. Now dock the “BindTestWindow“ and the Profiler tabs side-by-side
10. Don’t move your mouse for a while and observe the graph in the “CPU Usage“ section

Expected result: Performance stays the same
Actual result: Performance downgrades significantly to consistent ~50 ms with an overhead every ~10 frames reaching ~66 ms (could vary depending on the machine)

Reproducible with: 6000.0.35f1, 6000.1.0b3
Couldn’t test with: 2022.3.56f1 - Not able to resolve the compilation errors without changing the Script functionality

Reproducible on: Windows 10 (22H2), Windows 11 (23H2) (reporter’s environment)
Not reproducible on: No other environments tested

Notes:

* As mentioned before, the specific performance measurements (in ms) might vary depending on the machine that the issue is tested on
* According to the reporter, in the “VisualTreeDataBindingsUpdater.Update” process, there are numerous unnecessary assignments (that involve the “DataBindingContext” and the “PropertyPath”) which leads to high overhead from the copying of these structures

  1. Resolution Note:

    UI Toolkit bindings are heavy abstractions that require information about the hierarchical context of the element being bound. When used carefully, they can help reducing the amount of code needed to update UI.

    By default, a CustomBinding object is updated on every tick and will compute its binding context from the hierarchy. To lessen the impact, your type could implement the `IDataSourceProvider` interface to return itself as the dataSource, which will shortcuit the hierarchical computation. You could also set the updateTrigger to WhenDirty to avoid updating it every tick.

    If you require to run some code without needing the binding context being computed, you can use the scheduler instead, it should have less of an overhead.

    That being said, performance is something we're always looking into and we have some plans to improve the overall performance of bindings. One example of this is to add an option to disable the binding update for an element that is disabled or not displayed.

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.