Based on discussions in wasi-http/#8, we should consider a return-value optimization that avoids calling realloc by instead allowing the core wasm caller to supply a (buffer, length) i32 pair as a param. From my perspective, the main questions to consider are:
- For this to be useful, the optimization needs to apply not just for
list/string return types but also result<string> and other nested cases. But how far should this go? In the limit, it could apply to any use of list/string that's not nested inside a list, but that's probably too far.
- If the return value is a dynamically-sized
list/string which needs more bytes than given, should it just fall back to calling realloc and can the caller then be expected to observe this case by noting that the returned pointer is not the same as the given one?
- Is the speedup worth adding the special case?
Based on discussions in wasi-http/#8, we should consider a return-value optimization that avoids calling
reallocby instead allowing the core wasm caller to supply a (buffer, length)i32pair as aparam. From my perspective, the main questions to consider are:list/stringreturn types but alsoresult<string>and other nested cases. But how far should this go? In the limit, it could apply to any use oflist/stringthat's not nested inside alist, but that's probably too far.list/stringwhich needs more bytes than given, should it just fall back to callingreallocand can the caller then be expected to observe this case by noting that the returned pointer is not the same as the given one?