Re: WASM memory access from JS

['Felipe Gasper' via emscripten-discuss]

> On May 21, 2024, at 6:52 PM, 'Sam Clegg' via emscripten-discuss 
> <emscripten-discuss@googlegroups.com> wrote:
> 
> On Tue, May 21, 2024 at 11:18 AM 'Felipe Gasper' via emscripten-discuss 
> <emscripten-discuss@googlegroups.com> wrote:
> 
> 
> > On May 21, 2024, at 1:52 PM, 'Sam Clegg' via emscripten-discuss 
> > <emscripten-discuss@googlegroups.com> wrote:
> > 
> > To access the wasmMemory from the outside you should be able to do 
> > `-sEXPORTED_RUNTIME_METHODS=wasmMemory` and then access it via 
> > `Module.wasmMemory`.
> > 
> > You can also use the `.buffer` property of any of the HEAPXX exports if you 
> > export any of those?
> 
> Ah OK. Which of these approaches is likely the more stable?
> 
> I don't imagine either of them will change any time soon.   However if you 
> are already exporting one or more of the HEAPXX views then that would be the 
> simpler/small approach I think.

I’ll give that a shot, then. Thank you!

>   
> > BTW, I'm curious about the "The safest approach is to load/compile the WASM 
> > every time gawk runs, but that’s quite slow." quote.   Have you measured 
> > this?   What platform are you running on?  Ideally we would like to make 
> > repeated running like this fast so folks like you do not have to do work 
> > arounds, e.g. via caching the re-using as much as possible.   Have you 
> > looked into using the `-sMODULARIZE` and then using the module constructor 
> > each time you want to run the program?
> 
> I’m already using MODULARIZE, actually. From what I could tell, calling the 
> module constructor instantiates WASM. I have a simple test that runs gawk 
> 1,000 times (to check for memory leaks); that test ran fairly slowly when I 
> had it call the module constructor for each invocation. By switching to just 
> clearing the memory between callMain() invocations I realized a visible 
> speedup.
> 
> I see.   Thanks for the feedback.   I have couple of followup thoughts:
> 
> 1. I wonder which part of the module constructor is taking time here

I would _guess_ it’s the WASM parse/compile. But I don’t know enough to say for 
certain.

> 2. I wonder if we can improve this?  Perhaps there is more caching we can do?

I would think the WebAssembly Module and Instance, at least, could be cached. 
Maybe the Memory, too, if the size doesn’t change?

> 3.  I wonder how significant this difference is in real world usage, outside 
> of a microbenchmark that runs gawk 1000 times?

I’m not sure, really.

My own concern is that I’m looking at using this in a log viewer. The viewer 
stores the log lines in a JS array, so it’s easiest to run WASM (gawk, jq, 
etc.) separately on each line.

Obviously it’s more sensible just to run WASM once, but that would mean bigger 
architectural changes for the log viewer, so I’m trying to avoid that.

cheers,
-Felipe Gasper

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/57F43CA7-7A32-41C9-86F4-9A1F8C4C09E1%40felipegasper.com.