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
While host calls are pretty fast these days, it's still useful to consider optimizations to reduce their number per request for really low-latency scenarios. This has come up in two areas so far:
@PiotrSikora mentioned in this comment that many requests have empty bodies, so perhaps consume could short-circuit the hop through incoming-stream, maybe with a variant like this.
@brendandburns mentioned in this comment the sequence of calls to create headers, then create a response, then make the request. Perhaps we could have some more one-shot options that do multiple of these at once.
Both seem like potentially good ideas to me but I'd be happy to hear more thoughts.
The text was updated successfully, but these errors were encountered:
fwiw, part of the motivation to reduce host calls is also to improve the security of the surface area. I believe it is easier to ensure the security of a single req(...) style call vs all of the memory manipulation of the various calls between guest and host.
It's also a cleaner abstraction for the implementor, so fewer bugs in the implementation.
While host calls are pretty fast these days, it's still useful to consider optimizations to reduce their number per request for really low-latency scenarios. This has come up in two areas so far:
consume
could short-circuit the hop throughincoming-stream
, maybe with a variant like this.Both seem like potentially good ideas to me but I'd be happy to hear more thoughts.
The text was updated successfully, but these errors were encountered: