-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
String append / concat #1280
Comments
Currently |
String can also convert to and from bytes, and there is |
Ah yes, that'd be a much more preferred approach. Thanks @jayz22 ! |
@jayz22 How can String convert to and from Bytes? I don't see any existing SDK functionality for converting between them, and I don't see any host functions for doing so either. |
Actually it would be easier since String can directly converted to/from raw bytes via the linear memory, so one way could be
no need to go through the Bytes. A unit test on the host side would be:
|
Writing the bytes into local memory requires alloc, or requires using a buffer repeatedly. The main goal of this issue is to not use alloc. Using a buffer is an option, but an expensive one I think. |
Maybe I'm missing something, but why would copying via linear memory expensive? The linear memory routines are designed for these type of repeated/large number of bytes manipulation. |
@jayz22 To add an append function to the SDK it needs to pick some arbitrary buffer size, then for loop over copying the bytes to the slice on buffer at a time, then back to the host. It seems like a lot of repetitive bytes pushing across the boundary for something that could occur entirely host side. Depending on what we pick as a suitable buffer size, and depending on the input size, it could be multiple host fn calls, and it's 2 host fn calls per buffer filled. Maybe we don't need to optimise this now, but this seems like the sort of thing host fns should do entirely host side. |
Yeah you are right, that would require picking a buffer size or using an allocator.
|
@willemneal mentioned today that the String type has no concatenation functionality and replicating it with the existing SDK API is pretty complex because the developer has to use an allocator.
We could explore how to add this to the SDK without a protocol change, although very likely a protocol change is required here.
This issue probably requires:
The text was updated successfully, but these errors were encountered: