You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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 aparam
. From my perspective, the main questions to consider are:list
/string
return types but alsoresult<string>
and other nested cases. But how far should this go? In the limit, it could apply to any use oflist
/string
that's not nested inside alist
, but that's probably too far.list
/string
which needs more bytes than given, should it just fall back to callingrealloc
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?The text was updated successfully, but these errors were encountered: