Editor becomes unresponsive in Remote tab when displaying expanded tree with large number of nodes (Godot 4.4)

[Trakaan]

Tested versions

v4.4.stable.official [4c311cb] : reproducible
v4.3.stable.official [77dcf97] : not reproducible

System information

Godot v4.4.stable - Windows 10 (build 19045) - Single-window, 2 monitors - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 1660 Ti (NVIDIA; 32.0.15.6603) - Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz (8 threads)

Issue description

When running a project in 4.4 that use about a large number of nodes (~64k), the editor's Remote tab becomes extremely unresponsive and eventually freezes.

In my project : there are about 600 instantiated scenes each with about 80 nodes (a mix of labels, buttons, sprites, panels, control, vbox, etc.) no custom class.
In the attached MRP I simplified it to 800 instantiated scenes each with 80 panels. (~64k nodes)

At project start:

• The Remote tab is already very laggy, even before expanding anything.
• The more I expand the remote tree, the more it slows down (5–10 sec delays per scroll or click).
• Eventually if I click expand all, the editor becomes fully unresponsive for 3–5 minutes each time I click or scroll in it.

While frozen:

• The OS shows the editor as "Not Responding."
• The window redraw indicator keeps spinning.
• Editor only becomes responsive again several minutes later or after collapse.

To note:

• This issue seems only affects the Remote tab. The Editor tab (for the same scene tree) works fine even when fully expanded.
• Rolling back to Godot 4.3 resolves the issue completely.

Steps to reproduce

1. Open the attached minimal project.
2. Run the main scene.

• It instantiates 800 scenes each with 80 children → total: ~64,000 nodes.

3. In the editor, go to the Remote tab.
4. Begin expanding the nodes in the remote tab
5. After some expansion, the editor enters a "Not Responding" state.

Minimal reproduction project (MRP)

mrp-lag-project.zip

[akien-mga]

Thanks for the report and the MRP.

I can reproduce the issue in 4.4.stable and 4.4.1-rc2 (not a full freeze for me on Linux but there's significant lag).
In 4.3.stable, there's a slight lag on each sync of the remote debugger, but otherwise it's responsive.

I tested intermediate dev snapshots, the issue seems to have been introduced in 4.4-dev4: https://godotengine.github.io/godot-interactive-changelog/#4.4-dev4

So it's likely to be a regression from #88427 too, like #102525, and thus likely indeed the same issue. But it wasn't clear from #102525 that the issue could still be reproduced so drastically after the mitigations we put in place.

CC @KoBeWi

[KoBeWi]

I tried profiling and don't see anything that would suggest icons as the cause. CowData<TreeItem::Cell>::size shows at the top.
#88530 could be the culprit. The tree lags continuously, with icons being the problem it would be one big spike.
(this also means that local tree should have the same problem)

[jaydensipe]

I tried profiling and don't see anything that would suggest icons as the cause. CowData<TreeItem::Cell>::size shows at the top. #88530 could be the culprit. The tree lags continuously, with icons being the problem it would be one big spike. (this also means that local tree should have the same problem)

This does come from #88530, commenting out _determine_hovered_item(); on line 5050 in tree.cpp gets rid of the massive freeze and brings the freeze time back to how it was in 4.3. The hovering still seems to work with this line commented out, but I'm sure there's some reason this is done in the create_item method?

[KoBeWi]

It ensures that created item is correctly hovered.
It doesn't need to be called every time though, it can be queued, so there is only one hover update when adding many items.