1 minute freeze after building C# project consisting of only empty txt files and empty scripts (since 4.1.dev4)

[J-Ponzo]

Tested versions

• Not reproductible in :
  v4.0.4.stable.mono.official [fc0b241]
  v4.1.dev1.mono.official [db13026]
  v4.1.dev3.mono.official [a67d37f]

• Reproductible in :
  v4.1.dev4.mono.official [5c2295f]
  v4.1.beta3.mono.official [ada712e]
  v4.1.2.stable.mono.official [399c9dc]
  v4.2.1.stable.mono.official [b09f793]
  v4.3.dev6.mono.official [89850d5]
  v4.3.beta.mono.custom_build [be56cab]

System information

Godot v4.3.dev6.mono - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 2080 (NVIDIA; 31.0.15.3623) - Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz (8 Threads)

Issue description

As the number of txt files/C# scripts grows, the project freezes longer and longer when you re-build, i.e.:

• Click Build from the toolbar after source changes
• Click Play from the toolbar after source changes
• Launch in debug mode from VisualStudio
• Click Rebuild Project from the MSBuild dock

For 128 scripts / 8192 txt files, the freeze lasts 56s on my computer.

As you can see from the "Tested versions" section, the problem seems to have been introduced with v4.1.dev4.mono.official [5c2295f]

Steps to reproduce

• 1 - download / extract the MRP

• 2 - open it with a .NET version of godot (double-click the godot exe then import the project https://docs.godotengine.org/en/stable/tutorials/editor/project_manager.html#opening-and-importing-projects)

• 3 - wait until the project is completely loaded. i.e. the FileSystem dock should contain something. (This may take a while)
  

• 4 - create the C# solution (Project => Tools => C# => Create C# solution)
  

• 5 - rebuild the C# project form the MSBuild dock
  

• 6 - spam-click the editor until it freezes

Minimal reproduction project (MRP)

editor-freeze-issue.zip

[J-Ponzo]

I was able to narrow down to the commit that introduced the bug. I think this is :

[a1f454fee353fadbdb6f7032b6458f92be46560c] C#: Add global class support

As it's my first time using git bisect, I attach a screen of the last steps so that somebody with more experience can double check that I haven't misunderstood.

[raulsntos]

Thank you so much for the detailed report. I can reproduce the issue and you seem to be correct about the commit that introduced it (#72619).

It looks like we're calling EditorFileSystem::update_file for every file:

godot/modules/mono/glue/GodotSharp/GodotSharp/Core/Bridge/ScriptManagerBridge.cs

Lines 430 to 434 in 2551986

	foreach (var scriptPath in _pathTypeBiMap.Paths)
	{
	using godot_string nativeScriptPath = Marshaling.ConvertStringToNative(scriptPath);
	NativeFuncs.godotsharp_internal_editor_file_system_update_file(nativeScriptPath);
	}

This method ends up emitting the filesystem_changed signal deferred.

godot/editor/editor_file_system.cpp

Line 1820 in 2551986

call_deferred(SNAME("emit_signal"), "filesystem_changed"); //update later

It seems Godot becomes unresponsive executing the callbacks to this signal, so if we could debounce the emission so the signal is only emitted once that could fix the issue.