While profiling a big performance bottleneck in my editor plugin I discovered that the root cause was my poor choice of setting mouse hover state information on node metadata using the functions mentioned in the title.
After applying the changes in this pull request all the lag disappeared:
Interestingly enough, godot 4.5 and lower did not show nearly as much lag which is why I only started noticing recently.
My question is: is this performance degradation worth a bug report?
I can make a reproducible sample for it, but I donāt want to waste anyoneās time because I used the metadata for an incorrect purpose in the first place.
Yes I corrected it, as can be seen in the diff I shared in the question; I moved the state information to the plugin code (where it belongs) in simple type variables, in stead of on the nodes being edited
But the question is: is the finding worth reporting?
Definitely worth reporting. Thereās already precedent for set_meta()/get_meta() performance regressions across Godot versions, so a reproducible 4.5 vs 4.6 benchmark would be useful to the maintainers.
The fact that switching away from metadata completely removes the editor lag makes this more than just āusing the API incorrectly.ā
Thanks, do you have a hyperlink to some reading material about this? Githubās issue interface is pretty hard to navigate and I donāt want to create duplicates.
That I agree with, but is it worth the work for the maintainers? I can imagine that developers use node metadata in high volume, but there is usually a good alternative.
Might be insignificant but is there any effect on the performance if you use StringName literals where appropriate over String literals? It shouldnāt matter much but to get a specific scope of potential causes
I donāt have a lot of spare time a.t.m, but I think it would be worthwhile to compare all the *_meta methods accross 4.4-4.8 with String and StringName respectively and look for any speed degradation between versions.
I would say it would ultimately depend on the actual hard numbers, but I wouldnāt expect the meta methods to be intended for hot code, might be something to document though
There also isnāt really any direct changes to the metadata handling in 4.6 that I can find, so not sure what it would be, might be unrelated to metadata
Iām marking this as the solution, because it kind of confirms my suspicion. An extra documentation line to go along with the *_meta methods to make this clearer may help someone not to make the same mistake, I guess.