godot: Lua-style Dictionary operations are slower
Godot version
4.0 e8f9cd8
System information
Windows 10 x64
Issue description
Some facts:
- Dictionary will implicitly convert StringName to Strings when used as keys
- Lua-style syntax uses StringNames for access
As a result, Lua-style operations are about twice+ as slow. Benchmark I used:
var d: Dictionary
var time: int
time = Time.get_ticks_usec()
for i in 1000000:
d.test1 = 1
d.test2 = 2
d.test3 = 4
d.test4 = 8
print("Lua assign: ", (Time.get_ticks_usec() - time) * 0.001, "ms")
time = Time.get_ticks_usec()
for i in 1000000:
d["test1"] = 1
d["test2"] = 2
d["test3"] = 4
d["test4"] = 8
print("Python assign: ", (Time.get_ticks_usec() - time) * 0.001, "ms")
d = {test1 = 1, test2 = 2, test3 = 4, test4 = 8}
time = Time.get_ticks_usec()
for i in 1000000:
var a = d.test1
var b = d.test2
var c = d.test3
var e = d.test4
print("Lua read: ", (Time.get_ticks_usec() - time) * 0.001, "ms")
time = Time.get_ticks_usec()
for i in 1000000:
var a = d["test1"]
var b = d["test2"]
var c = d["test3"]
var e = d["test4"]
print("Python read: ", (Time.get_ticks_usec() - time) * 0.001, "ms")
My results:
Lua assign: 1746.421ms
Python assign: 693.359ms
Lua read: 1985.207ms
Python read: 862.008ms
I think Lua-style dicts should use Strings, to avoid useless conversions.
Steps to reproduce
See above.
Minimal reproduction project
N/A
About this issue
- Original URL
- State: open
- Created 2 years ago
- Reactions: 4
- Comments: 26 (26 by maintainers)
So here’s my takeaway right now. Sorry to spam you all, but I’m enjoying digging into this one. Feel free to take your time to read (or just ignore!). TL;DR at the end.
Currently,
String-based accesses are 25% faster thanStringName-based accesses.Across the board, if your method for accessing a dictionary uses a
String, then it’s the fastest it can be on themasterbuild. Any access which usesStringNames, such as doingdict.this_is_a_stringnameordict[&"this_is_a_stringname"], has a performance penalty to the tune of about 1/3.That difference in-editor is actually closer to 40-50% faster for String-based methods
For whatever reason, being in editor (I suspect just meaning
TOOLS_ENABLED) significantly exacerbates the difference betweenString- vsStringName-indexed methods. No idea why that would be, but the big difference doesn’t appear between release and debug builds, so it has to be the editor.StringName-based dicts could be up 10% faster than String-based ones
According to @rune-scape’s test of performance before and after the merge for unifying
StringandStringName:This means that fully
StringName-based dicts (withStringName-based accesses) could be significantly faster in the grand scheme of things. Right now this isn’t possible since all dictionaries are implicitly converted to beingString-based only.If sticking to String-based dictionaries, #68925 fixes lua-based access underperformance by ~25%
Lua indexing like
dict.my_propis effectively forced to useStringName. InString-based dictionaries, that requires conversion fromStringNametoString, which has some cost.TL;DR (aka my conclusion): having a
StringName-based dictionary is worth it. If this is done, then #68925 should probably not be merged.If we were to have something like
my_dict.allow_string_name_keys(true), then I believe we would get the fastest possible results. For performance-critical parts of the code, or data-driven game architectures,StringNamebased access could provide a 10% increase in performance, which is significant.If this is something that we want to have in godot, then forcibly reducing lua-based
StringNameaccesses toString-based accesses, like what #68925 is doing, is probably a terrible idea 😃I’ve tun into some memory issues, but wanted to leave this little exciting bit of progress 😃
Silly example, but it’s worth noting that StringName access is for some reason faster when the keys are long enough (int performance added for reference):
gives me this on 4.2 dev2 (running from the editor):
“Python assign StringName” being a weird outlier there.
While in the shorter-named version, Strings are of course faster as established:
thank you for the graphs @anvilfolk! they make my autism happy 😃 but to be clear, the String conversion happens at a low level in c++, so a runtime switch wouldn’t really make sense
Should be fixed by #68747.
So I got a weird idea. Right now most of the Dictionary code looks like this: https://github.com/godotengine/godot/blob/015dc492de33a41eaeb14c0503a6be10466fe457/core/variant/dictionary.cpp#L103-L108 What if it instead was
(note the
has()check)?Implicit Strings would become a fallback rather than being forced. Assuming that checking for some value is faster than casting to String, this could improve performance. The problem is that it needs to work 2-way, i.e. Strings should work with StringName keys. Also I wasn’t able to figure out how to allow assigning StringName keys, because Dictionary seems to use
[]operator for both reading and writing.with #68747 i got these numbers (i added a StringName benchmark):
the only way i can think to make it faster would be to actually store StringName keys in Dictionaries instead of converting them (or convert attributes to Strings specifically for Dictionaries, but that seems hacky to me)
it doesn’t completely fix this though, because it’s still slower i would have removed the StringName to String conversion in Dictionaries, but there was 1 piece of code that failed when i tried, and i was worried there might have been more i couldn’t find
Working on this one 😃 Think I have one possible cause of the issue narrowed down.
The lua style is using a
subscriptthat hasis_attributeset totrue, whereas the python style is also using the same thing, butis_attributeisfalse. I’m going to try to reduce the first case to the second when thebaseis known to be a dictionary and theattributecan’t be found in the builtin methods/properties.