Skip to content

Conversation

@pixelherodev
Copy link
Contributor

Slight speed-up for a few string conversions.

Strings are immutable. As such, string([]byte(foo)), given a mutable buffer, must copy the string, so that changes to the underlying slice do not break the language's requirements.

unsafe.String(foo, length), instead, crafts a string header pointing to the existing buffer. So long as that buffer is never modified for the lifetime of the string, this can be totally safe, and is faster.

Since the flatbufs will never be modified, it's totally safe to craft strings that point directly into its innards. The string pointer is sufficient to prevent GC, and we never modify that flatbuf data on read paths.

Tests pass and there's a small but measurable performance improvement in profiles I was looking at.

@zeroshade
Copy link
Member

do we see any measurable performance difference in the existing benchmarks?

@pixelherodev
Copy link
Contributor Author

I don't think so.

For the profiles I was looking at, the rate of timestamps was sufficient that this minor savings was happening millions of times per second, and was still pretty small, I think. I can double check, but this one might be worth skipping, yeah.

@zeroshade
Copy link
Member

@pixelherodev can you fix the lint issue any the failures here?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants