On Wed, Dec 10, 2025 at 8:38 AM chris goyette <[email protected]> wrote:
> What I do not understand is the access cost. How many function calls are > involved, and are we likely to thrash the cache in the process? I honestly > do not know. I do not expect anyone in the group to answer this in detail, > but I anticipate using Emscripten far more often in the coming years, and > these are things I will need to understand. > > I have looked at wire.h and tried stepping through some of the relevant > functions. Learning this way, by reading source code, is always difficult, > especially when heavy template logic is involved. I was really hoping for a > Udemy course or something similar, but everything I have found so far is > very surface level. A conference talk would work just as well. Anything > where someone explains the concepts directly would be far more effective > than me fumbling my way through source code :P > There was a great talk some years back which ...... I believe is this one: https://www.youtube.com/watch?v=Dsgws5zJiwk It's from 2014 so it talks about asm.js and such first -- the embind stuff comes in about 10 minutes in. IIRC the embind internals are pretty much the same as they were then and this goes into some more details on how it works under the hood which I think should help demystify it. :) The bits on 'wire types' and embind's handles for JavaScript objects should help clarify memory management / lifetime / boundary. Since much of the embind magic is set up by templates it's hard to see the costs from the high-level view indeed. :) Couple quick things off the to of my head from previous times working with embind: In general, passing around a JavaScript object by reference is very cheap because you're just passing a handle id wrapped in an emscripten::val -- while actually accessing data through it will end up calling through to JavaScript. The JS side of embind keeps a big array I think with the handle -> object references. Integers and floats? Also cheap. Meanwhile passing strings or buffers/arrays to/from JavaScript is expensive because it requires copying/conversion of data types. Data you export as a memory view becomes a Typed Array view into the WebAssembly memory, and is *very cheap* to return and to access. However it's your responsibility to manage the lifetime of the view responsibly compared to the lifetime of the underlying data -- if you free and reuse the underlying data while the view is still active it will show incorrect data. -- brooke -- 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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/emscripten-discuss/CAFnWYTmmv9my%2BsO%3DXKze0r6mDAOB65AGKT1w8r9R-s4viqT9KA%40mail.gmail.com.
