You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the problem or limitation you are having in your project
Godot is currently using a split implementation for StringName internally:
StringName initialized from static C strings is using const char *.
StringName initialized from Strings, and unequal to a static C string on initialization, is using String.
Using a split has 3 downsides:
StringName to String conversion needs to copy the string anew for each invocation.
StringName implementations are somewhat slower because they need to jump, leading to branch mispredictions, adding a small cost to calls.
StringNamechar * paths are slower because length is not known (though this could be solved with spans / StrRange).
Using a split has two upsides:
StringName creation from static strings is fast, because no string has to be allocated
The difference applies only when no previous StringName had existed for the string. In this case, the StringName has to be inserted into the database, and there is overhead anyway.
StringName of static C strings needs less RAM because they can point to char* of the source code.
I have measured the potential RAM use of StringName of static C strings and conversion call counts on a launch through the project launcher and into a project with 10k nodes.
RAM use was measured at 1mb (~200k characters) from 12k strings.
There were 40k calls to operator String(), each allocating new memory for a string.
It is somewhat questionable if 12k different static c string StringNames should even exist in Godot; I hope somebody has an insight into that. I suspect the StaticCString constructor may be misused for translations or similar, skewing the numbers.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
Godot could switch to always use String internally in StringName.
This would cost it upwards of 1mb in memory, but speed up String interoperation.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
N/A
If this enhancement will not be used often, can it be worked around with a few lines of script?
No.
Is there a reason why this should be core and not an add-on in the asset library?
It's core.
The text was updated successfully, but these errors were encountered:
It is somewhat questionable if 12k different static c string StringNames should even exist in Godot; I hope somebody has an insight into that. I suspect the StaticCString constructor may be misused for translations or similar, skewing the numbers.
You can run Godot with --debug-stringnames so it prints statistics on StringName usage on exit.
Describe the project you are working on
Godot performance.
Describe the problem or limitation you are having in your project
Godot is currently using a split implementation for
StringName
internally:StringName
initialized from static C strings is usingconst char *
.StringName
initialized from Strings, and unequal to a static C string on initialization, is usingString
.Using a split has 3 downsides:
StringName
toString
conversion needs to copy the string anew for each invocation.StringName
implementations are somewhat slower because they need to jump, leading to branch mispredictions, adding a small cost to calls.StringName
char *
paths are slower because length is not known (though this could be solved with spans / StrRange).Using a split has two upsides:
StringName
creation from static strings is fast, because no string has to be allocatedStringName
had existed for the string. In this case, theStringName
has to be inserted into the database, and there is overhead anyway.StringName
of static C strings needs less RAM because they can point to char* of the source code.I have measured the potential RAM use of
StringName
of static C strings and conversion call counts on a launch through the project launcher and into a project with 10k nodes.RAM use was measured at 1mb (~200k characters) from 12k strings.
There were 40k calls to
operator String()
, each allocating new memory for a string.It is somewhat questionable if 12k different static c string
StringNames
should even exist in Godot; I hope somebody has an insight into that. I suspect theStaticCString
constructor may be misused for translations or similar, skewing the numbers.Describe the feature / enhancement and how it helps to overcome the problem or limitation
Godot could switch to always use
String
internally inStringName
.This would cost it upwards of 1mb in memory, but speed up
String
interoperation.Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
N/A
If this enhancement will not be used often, can it be worked around with a few lines of script?
No.
Is there a reason why this should be core and not an add-on in the asset library?
It's core.
The text was updated successfully, but these errors were encountered: