Currently, static representation takes priority over inline.
For example, Atom::from("bananas") performs the following operations:
- Calculate hash of "bananas".
- Calculate index in static set (several arithmetic operations).
- String comparison of "bananas" and the string in the static set at that index.
If "bananas" is not in the static set, it falls back to inline representation.
Is there a reason why strings of 7 bytes or less don't skip all the above, and go direct to using inline representation?
As far as I can see, inline representation is much cheaper, and which representation takes priority doesn't matter for the rest of Atom's implementation - as long as it's consistent.
Short strings could still be input to the codegen so they can be used in atom!(), but codegen would not add them to the static set, and instead generate pack_inline() calls (instead of pack_static()).
I can't see any downside to this, and imagine it could be significantly more performant for use cases where there are lots of short strings in use. But am I missing something?
If you think this may be worth looking into, I'd be happy to implement and benchmark.
Currently, static representation takes priority over inline.
For example,
Atom::from("bananas")performs the following operations:If "bananas" is not in the static set, it falls back to inline representation.
Is there a reason why strings of 7 bytes or less don't skip all the above, and go direct to using inline representation?
As far as I can see, inline representation is much cheaper, and which representation takes priority doesn't matter for the rest of Atom's implementation - as long as it's consistent.
Short strings could still be input to the codegen so they can be used in
atom!(), but codegen would not add them to the static set, and instead generatepack_inline()calls (instead ofpack_static()).I can't see any downside to this, and imagine it could be significantly more performant for use cases where there are lots of short strings in use. But am I missing something?
If you think this may be worth looking into, I'd be happy to implement and benchmark.