-
-
Notifications
You must be signed in to change notification settings - Fork 21.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
doc: Clarify when to construct a StringName ahead of time #79815
Conversation
When using the I think we should keep the original wording with "occasionally" as it should be done occasionally, depending on situation and not done too much Also while I haven't verified it for built-in functions this optimization might be done for constant expressions anyway Edit: It does indeed automatically convert constant strings to func do_test(_var: StringName, _var2: String):
pass
func test():
do_test("abc", "def") Yields:
This also happens with built-in functions such as those of |
Ooh, great! It does even better than I expected! Preference of either of these:
I think the original use of "occasionally" was wordy, but understand the desire to discourage. Could also say "when the disassembler shows its necessary" with a link to how you disassembled but it doesn't look like there's a docs page for it. |
I went with "in rare cases". Ready for review again. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This actually looks really good. The "nudge" to use normal Strings with wording is great.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would be nice to tweak it slightly but it's better than the original description. StringNames don't offer much advantages for most common users and they need to know.
Fix docs don't give justification for manual construction. Clarify how to apply manual StringName construction as an optimization and that "string intern" means "work at parse time". There are several godot-demo-projects (including 3d/platformer) that incorrectly use StringName literals (they use & literals instead of just passing strings), so clearly this is confusing. AThousandShips did a disassembly test to prove it automatically converts constant strings to StringName for annotated functions: func do_test(_var: StringName, _var2: String): pass func test(): do_test("abc", "def") Yields: Disassembling do_test(_var, _var2) 0: line 2: pass 2: == END == Disassembling test() 0: line 5: do_test("abc", "def") 2: call self.do_test(const(&"abc"), const("def")) 10: assign stack(3) = false 12: == END == It also happens with built-in functions such as those of Input.
Thanks! And congrats for your first merged Godot contribution 🎉 |
I'm not certain my edit is 100% correct.
Clarify that manual StringName construction is an optimization for controlling when you pay the construction cost. Avoiding the word "optimization" so people don't use
&""
everywhere by default.Old text:
That immediately suggests the question: when and why?
I can only think of performance reasons:
process
or especially in a tight loopI assume there's never a non-perf reason?
Uncertainty
I looked up the docs because the finite_state_machine demo uses &"" for
Input.get_axis
:I assume this is a good example of how to optimize with
&""
and that using the literal&""
constructs the 4 StringNames at parse time and not per invocation ofget_input_direction()
?If that's incorrect and this is the correct optimization:
Then a better final line would be: