Can `StringName` literals be optimized?

[Des-Nerger]

If I've understood it correctly, constructing a StringName once and then doing .clone() of it is non-negligibly more efficient than constructing it of &str from scratch every time we need a StringName to pass to the Godot API. So, naturally, .clone() should be used quite often:

  fn init(base: Base<Self::Base>) -> Self {
    Self {
      velocity: Vector2::ZERO,
      input: Input::singleton(),
      ui_left: "ui_left".into(),
      ui_right: "ui_right".into(),
      ui_up: "ui_up".into(),
      ui_down: "ui_down".into(),
      base,
    }
  }

  fn process(&mut self, delta: f64) {
    let o /*bject */ = self;
    o.velocity =
      o.input.get_vector(o.ui_left.clone(), o.ui_right.clone(), o.ui_up.clone(), o.ui_down.clone());
    ...
  }

So, why not do #[derive(Copy)] on StringName to make it less hairy?

[lilizoey]

deriving Copy means that cloning something is simply doing a bitwise copy of the data. thus it also prevents anything like refcounting from working since we can't implement Drop for instance. so we cannot do this.

we could probably make more functions like this accept a reference and automatically clone them where necessary though.

[Bromeon]

There is this method to construct from raw strings without extra allocations, but it's a bit more cumbersome to use.

The approach you show with clone() is possible, but leads to very verbose code. Generally this would be a use case for StringName constants, but in Rust those are quite a pain:

• const would require an initializer with a const fn, which can't call FFI. It would also duplicates all instances.
• static may be possible, but also has the issue that instances are never destroyed, meaning that those show up as leaked string names when shutting down Godot in verbose mode (this is already a problem)
• a macro like string_name!("...") which caches the StringName -- that also somewhat defeats the purpose, since it's supposed to be fast to construct.

Generally it's good to optimize for performance, but gdext's primary goal is pragmatism. I don't want to encourage code patterns that lead to complex code, in an attempt to save a few cycles in cold paths. It would really surprise me if constructing 4 stringnames per frame would be the bottleneck of a game. If we're talking about a hot loop or 10ks of entities, it's another story.

[Bromeon]

If I've understood it correctly, constructing a StringName once and then doing .clone() of it is non-negligibly more efficient than constructing it of &str from scratch

This would by the way be something interesting to measure. I specifically added support for direct construction in godotengine/godot#78580, but it currently still needs to go through String due to UTF-8 parsing.

There is the StringName(const char* p_name, bool is_static) constructor, but I think it expects UTF-32 just like String. However, &str is UTF-8. We likely can't avoid the allocation when converting to UTF-32, not without limiting the string size.

---

Thinking a bit more about this, a sname!("hello") macro could be interesting. Implemented as a proc-macro, it could transform the &str literal into a [char; 5] or [char; 6] (null-terminated) UTF-32 string literal at compile time. There's currently no GDExtension API that accepts UTF-32 strings for StringName, but it might be possible to add.

On the other hand, I'm also a bit conflicted. Using "..." literals is very nice, and in 99% of cases fast enough. If we encouraged a sname! or s! or similar macro to be used all the time, code would become quite a bit uglier, at no real benefit. It creates a fear-of-missing-out situation, where people get an ungood feeling if they don't apply all the optimizations.

[Des-Nerger]

fear-of-missing-out

If you didn't impl From<&'static str> for StringName, it would ease the fear, I think.

[Bromeon]

If you didn't impl From<&'static str> for StringName, it would ease the fear, I think.

I was actually considering this; but I'm not sure if it's worth the ergonomic penalty.

This is not just about literals but also conversions from pre-existing string slices; although I guess we could use an explicit constructor for those.

[lilizoey]

Couldn't we have from_latin1_with_nul accept a &'static CStr, then with rust 1.76 (to be released in early february) people can just use c string literals to initialize this?

[Bromeon]

That sounds very interesting -- more on C-string literals here 🧐

[lilizoey]

with #652 merged, you can now efficiently construct StringNames using c"some string".into() or StringName::from(c"some string"). this should be faster than even cloning a StringName, though this isn't benchmarked.

I believe this should be a sufficiently good solution to this issue. If you need the performance you can simply replace usage of string literals with c-string liteeals and thus avoid utf-8 parsing entirely as well as any reference counting. And im skeptical this could be optimized much more than that.

So ill close this. if there is a concrete use-case for optimizing StringName literals further than this that isn't covered by this then feel free to re-open.