Repository: godot
Issue: Control theme changes in 3.X resulting in some considerable performance regressions 
Labels: bug,topic:editor,regression,topic:gui,performance

### Godot version

3.5

### System information

All

### Issue description

After upgrading to 3.5, this commit:

https://github.com/godotengine/godot/commit/58319564fa8c169aa9036225461ae2e1b859c6d4

Has resulted in a significant performance regression when trying to use the editor.  We encounter long delays in the engine whenever the error log is spammed, and opening any project that outputs a lot of errors results in the engine hanging when opening the project, or taking a very long time.

A quick profile on the engine when this degradation is happening now shows most of the engine's CPU time is spent here `EditorLog::add_message`.  I've expanded most of the stack frames at this callsite to get a more in-depth look into where the cpu is spending it's time:

<img width="1033" alt="Screen Shot 2022-08-10 at 1 43 28 PM" src="https://user-images.githubusercontent.com/323868/184006070-34cad82d-2999-480a-b893-6f1b6479eb20.png">

The TLDR is: now, a basic system that should be striving to be ultra fast (printing to editor log) is slowed down by theme code that is expensive.  

From the profile report, you can see 15% of my cpu is spent in `EditorLog::add_message`...  And within that function, all the calls to `get_color` `get_icon` are extrememly slow.  

Due to https://github.com/godotengine/godot/commit/58319564fa8c169aa9036225461ae2e1b859c6d4 `Control::get_color` and `Control::get_icon` now do a lot of additional processing and checks, but most importantly they ultimately end up allocating and deallocating memory now.  These functions now run through various checks like `Theme::_get_type_dependencies()`, which uses `List<>` as a temporary stack object, and push various temporary heap objects to these lists for the purpose of checking theme stuff.   This overhead really slows down these functions, as these simple getters on a Control should be lightning fast.  But now there is a lot of internal bloat on these getter functions.  Here's the expansion on `Control::get_color` now:

<img width="864" alt="Screen Shot 2022-08-10 at 2 00 28 PM" src="https://user-images.githubusercontent.com/323868/184008942-5b87aa21-6748-4480-8f27-6e1913b6a90b.png">


The second issue with the aforementioned mentioned commit, and from the profile snapshot, is that a lot of time is also spent in `StringName::~StringName`.  I can see from that change that a lot of empty StringNames are initialized in various places throughout this commit.    But construction and destruction of these temporary objects is really not free, and apparently destruction of StringName object requires mutex lock:

<img width="1029" alt="Screen Shot 2022-08-10 at 1 57 42 PM" src="https://user-images.githubusercontent.com/323868/184008472-09ac1bf6-f016-4e8a-b7e7-d6b7af3ba389.png">



  

### Steps to reproduce

Spam the Engine's error log and profile the engine's cpu time...  Also can get very high performance regression by just having a lot of lines in the Engine's output panel.

### Minimal reproduction project

_No response_