Severe regression in asset import speeds

[Jamsers]

Tested versions

• Reproducible in: v4.3.rc2
• Not reproducible in: v4.2.2.stable

System information

Godot v4.3.rc2 - Windows 10.0.22631 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3060 Laptop GPU (NVIDIA; 32.0.15.6070) - AMD Ryzen 5 5600H with Radeon Graphics (12 Threads)

Issue description

First off, I will say that it feels like pretty much everything is slower in 4.3. Even simple things like changing project settings. But this one is the most egregious - it completely annihilates iteration speed.

4.2 import times:

4.2.Import.mp4

4.3 import times:

4.3.Import.mp4

It applies to all kinds of assets - so even something like creating a new material involves wait times of up to a minute.

Steps to reproduce

I have not confirmed yet, but the issue seems to only show up on large projects.

On Crater-Province-Level, to reproduce the video example:

• Open project in Godot
• Open Asset Sources/Model/Tunnel_All.blend in Blender
• Export as glTF to Models/Tunnel_All.glb
• Switch back to Godot window and wait until scene window is responsive again

Minimal reproduction project (MRP)

Crater-Province-Level:
test-4.2 branch

[Calinou]

Can you test all pre-releases between 4.2.2 and 4.3.rc2 to help bisect the regression? You can download them here.

Make sure to remove the .godot/ folder between each test.

Note that #93877 may crop up if you have V-Sync disabled in the project settings, as V-Sync in the editor is now controlled by an editor setting since 4.3 (the project setting is ignored by the editor).

[Jamsers]

#93877 was actually my first guess, but disabling (editor) vsync and enabling continuous update didn't seem to help, so I reported this separate issue.

I'll try to bisect soon when I have the time.

[Jamsers]

Finished bisecting. The regression was introduced with commit 846bafd.

[akien-mga]

That's #92279, CC @SaracenOne @lyuma @fire.

[fire]

TODO: get a profile to see what is slow

[lyuma]

If this is related to that commit, it should be caused by the code to handle refreshing the open scenes, not the editor scene import system

can you verify if import is fast when there are no scenes open (close all scenes before saving the glb, and see how long until the editor is responsive)

That way we can rule out the core import system and focus instead on optimizing refreshing the open scenes.

[Jamsers]

Just tested, import is blazing fast when all scenes are closed. Also noticed while testing that closing and opening a scene is really slow, especially big scenes.

[Hilderin]

I'll do some debugging on that. On my computer I see way worst performance problem then @Jamsers with the MRP. Just opening a scene could take 1 min. and reimporting takes almost 2-3 min. On a debug build, it's even a lot worst.

[Hilderin]

So far, I found 2 main problems:

• When opening the scene, the it takes 40 sec to request gizmos. When I comment Node3DEditor::_request_gizmo and Node3DEditor::_request_gizmo, it's down to 25 secs and the Editor is way more responsive right after the scene is loaded.
• There are definitively some regression caused by Fix instanced .blend/GLTF scenes lose all children after update until .tscn is reopened #94093. Currently, preload_reimporting_with_path_in_edited_scenes take 9 sec and update_node_reference_modification_table_for_node 9 sec when reimporting. I'll look into the performance for reload the scene when reimporting.

[Hilderin]

I think I'm on the right track, finally, the major issues were from e57312d and #90531.

• e57312d caused an iteration on all node in the scene to find every modifications with update_node_reference_modification_table_for_node.
• Fix errors when re-importing 3D asset files #90531 caused a removal and an add of the scenes on the reimport process.

I need to retest a lot of things from #94093 to see if I did not break anything and check how to fix e57312d and #90531 another way before creating a PR.

godot.windows.editor.dev.x86_64_ZohJkASVm4.mp4