Repository: godotengine/godot (language: cpp)

Issue:
GDScript code completion is extremely laggy on Android Editor
### Tested versions

Reproducible in build of current master branch - Godot v4.4.dev (8004c7524).
Not reproducible in 4.4.dev3 / 4.3 stable

### System information

Godot v4.4.dev (8004c7524) - Android 14 - Single-window, 1 monitor - Vulkan (Mobile) - integrated Adreno (TM) 618 -  (8 threads)

### Issue description

GDScript autocomplete is now extremely laggy on the Android editor, with the editor freezing until the code completion dialog appears. The code completion delay and  idle auto parse delay are in their defaults.
This does not happen on 4.4.dev3 or earlier.

### Steps to reproduce

Just create a gdscript and type anything that prompts auto complete.

### Minimal reproduction project (MRP)

None


Discussion / hints:
Just to rule that out from the get go: Are you comparing a self-build Godot editor to the prebuild one from the Website? If so please build 4.4.dev3 yourself to make sure that this is not just an issue with compiler optimization. FYI 4.4.dev3 is built from commit f4af820 .
> Just to rule that out from the get go: Are you comparing a self-build Godot editor to the prebuild one from the Website? If so please build 4.4.dev3 yourself to make sure that this is not just an issue with compiler optimization. FYI 4.4.dev3 is built from commit [f4af820](https://github.com/godotengine/godot/commit/f4af8201bac157b9d47e336203d3e8a8ef729de2) .

I have been regularly testing with the build artefacts from CI after every commit. This behaviour wasn't there in last week's builds. I just mentioned 4.4.dev3 because it is the most recent official build. I also compiled master with `production=yes` and `speed=optimize`, but still get the same behaviour.
Ok, on `git bisect`ing i found https://github.com/godotengine/godot/pull/88427 to be the problem. On reverting those changes, rebasing on master, and recompiling, the problem went away. Can anyone else confirm if this a bug?
Sounds like a performance regression.

We use the method to get an icon from a class name for every completion option, so the changes in there are probably to heavy to call for each completion option.

This seems like it could impact performance quite a bit:
https://github.com/CrayolaEater/godot/blob/fb58ea6c89ff3f9e970e436982c76e96adccdefc/editor/editor_node.cpp#L4845-L4846
Maybe a lightweight check on the script name before calling `ResourceLoader.exists` could prevent this. But personally I don't think `get_class_icon` should handle script paths at all, from its name I would assume it only handles class_name and native class names.

Fix patch:
diff --git a/editor/editor_node.cpp b/editor/editor_node.cpp
index 40848610c62a..fc2a65565ab9 100644
--- a/editor/editor_node.cpp
+++ b/editor/editor_node.cpp
@@ -4941,7 +4941,7 @@ Ref<Texture2D> EditorNode::get_class_icon(const String &p_class, const String &p
 	String script_path;
 	if (ScriptServer::is_global_class(p_class)) {
 		script_path = ScriptServer::get_global_class_path(p_class);
-	} else if (ResourceLoader::exists(p_class)) { // If the script is not a class_name we check if the script resource exists.
+	} else if (!p_class.get_extension().is_empty() && ResourceLoader::exists(p_class)) { // If the script is not a class_name we check if the script resource exists.
 		script_path = p_class;
 	}
 


Test patch: