Replace VMap used in VisualShader with HashMap and remove VMap

[YYF233333]

Build on top of #100440

I’ve only just started looking at these code, please point out if I miss something.

A VMap provides array based ordered storage for a series of key-value pairs and offers a map-like interface. Currently it is only used in VisualShader code, and only three methods are used: insert, has and operator[]. It seems the user just want a normal Map. So I replace it with HashMap.

Performance wise HashMap should be faster (O(1)) compared to VMap (O(log(n))) theoretically, but I barely use visual shader and have no idea how to bench this.

This together with #100440 will obsolete VMap, shall we remove it or not?

[YYF233333]

Found this while cleaning my stale PRs. Seems nobody really cares VMap? Also I still can't find anymore usage, so I'd like to propose that we can remove this nearly unused container.

[akien-mga]

Yeah if there's no downside to moving to HashMap, I'm fine with removing VMap. CC @godotengine/core

This technically breaks compatibility for thirdparty C++ modules which may rely on it, but if they do they can simply copy the vmap.h file in their own module.

[Ivorforce]

It's a good candidate for removal. I'll bring it up at the next core meeting.

[Ivorforce]

We discussed this proposal in the core meeting. We agreed that generally, this is a good idea, and if we proceed with it there's it's fine to remove VMap to lighten the codebase (cc @reduz, the author, in case you want to keep it).

However, given that this deals with shaders, we need to be very sure that this PR that this PR doesn't cause performance regressions, so benchmarking it is absolutely needed for it to be merged.

Personally, I'd try to familiarize myself with visual shaders enough to get a feeling for how to benchmark it, then benchmark it in place with a very demanding task. Perhaps someone from @godotengine/shaders has any tips? :)

It may also be enough to show that the code isn't called often and is thus risk-free, but one use is in _update_shader so I'm not sure if that's the case.

[YYF233333]

I took some time to familiarize myself with VisualShader and ran a simple stress test. My conclusion is that VMap is not a performance bottleneck.

I commented out these lines, forcing VisualShader::_update_shader() to always update the shader. (Note: Modifying this will cause a crash when opening the VisualShader editor, so don't try to view the shader.) Then, I called _update_shader() every frame to create a heavy load.

Profiling results show that most of the time is spent on shader compilation rather than the VisualShader-to-Shader conversion. Even within the conversion process, VMap accounts for only a small portion of the overhead (0.5% or so). Most of the time is spent on string operations.

Test project: test_visual_shader.zip

I have difficulty finding or creating complex visual shaders (the code seems clever enough to skip disconnected nodes so I can't just add bunches of nodes). If someone can provide a complex shader I'm happy to test it.

[akien-mga]

Let's go ahead with it, sufficient testing was done IMO and we can always reconsider if users report regressions.

[Repiteo]

Thanks!