Cost of the function call throught host/guest boundary

[ur-fault]

I am planning on using Extism as mod system for my TUI game. One of the most important functionality of the system would be having mods draw to the screen.

There are two possible ways to go about this:

1. having mods render to the kind of buffer they keep themself and return it
2. app itself would host they buffers and they would issue render instructions to it, in my understanding of the X system, it would be similar

In any case, app would need to call minimally draw function of every mod every frame. Is it viable to do using Extism?

In the latter case, Extism would need to handle possible hundreds of host calls per frame. Would this be viable?

[mhmd-azeez]

Hi, what SDK are you using? If you're using the Rust SDK, you can check out these benchmarks to get a better idea on the performance characteristics:
https://github.com/extism/extism/blob/main/runtime/benches/bench.rs#L42

[mhmd-azeez]

Also, check out this benchmark for the php-sdk (which is wrapping the Rust SDK):
extism/php-sdk#8 (comment)

Extism function calls are pretty fast, but in the end you might want to do your own benchmark to see if it's fast enough for your use case

[ur-fault]

I am using the Rust SDK, so I will check out these benchmarks.

Thanks a lot for your response

[bhelx]

I think the overhead for a host function is just a few nanoseconds. @chrisdickinson could probably say more. Your performance will be bottlenecked more by how much data you need to push across. Reading our benchmarks will help but it's best to come up with your own that pushes across an expected amount of data into that host buffer and measure that. Unless it's a super high resolution buffer I suspect your performance will be acceptable using host functions.

[bhelx]

If you measure both approaches let us know the results!

[ur-fault]

Sure, once I get to it, I will post them

[lukevp]

If I had to guess, drawing to the console will be the slowest part of this whole thing, if you're using Rust on both sides. Consoles aren't always super fast to render updates. The second slowest thing is probably going to be the ser/de you're doing to send data across the boundary. Defining a messagepack or raw binary interface between the two would probably speed things up quite a bit.

Also, you could have the plugin own the memory space for the buffer and not return it, and instead return a pointer to it. he host is able to introspect the guest memory without copies, so you may be able to optimize it that way. At least that's possible in wasmtime, I'm not sure if Extism allows that or if host parameters are always wrapped and copied.

But benchmarks are king, and premature optimization is the root of all evil, so test it before you determine it's even an issue. wasm is unbelievably fast.

[ur-fault]

I know that consoles are pretty slow, as any other buffer manipulation with OS, but I wouldn't want to introduce another reason for there to be bigger delay than there already is. I plan on using msgpack for this.

If it's somehow possible to return pointers, it would probably be the best option, since they can manage it however they want and treat it as something akin to the image buffer in the graphics programming.

Also, I apologize for not responding, I hope to get to the benchmarks soon.