Do you still have a penalty when e.g. manipulating a TypedArray from JS?

(If so, this seems like a regression compared to unoptimized asm.js.)

No, these have very well optimized fastpaths in all engines.

The method I'd expect for high-throughput communication between js and wasm would be for the wasm code to build structures directly in memory and for JS to traverse those directly using the memory buffer (TypedArray, but really ArrayBuffer).

TypedObjects in ES* will let you directly build lightweight JS objects that are just pointers into an ArrayBuffer.

Edit: Updated to note the fact that I really don't know what the status of TypedObjects is currently..

It's hard to find out. Noone really seems to be talking about it.

It is enabled in Firefox nightly, though I don't know if the API is stable yet:

    > var Point = new TypedObject.StructType({x:TypedObject.int32, y:TypedObject.int32})

    undefined

    > new Point({x:1, y:2})

    InlineTransparentTypedObject { x: 1, y: 2 }

There is a Mozilla bug from last February [https://bugzilla.mozilla.org/show_bug.cgi?id=1336740] that proposes that MDN document that particular TypedObject API, since it was experimentally implemented by Firefox. Florian Scholz of Mozilla then commented:

> The TypedObject proposal predates ES2015 and the yearly release model ECMAScript is on now. That said, the Firefox experimental implementation is not based on current standards work. I'm not sure how useful it is to further advertise or to document it in this case.

Lars T. Hansen of Mozilla added:

> IMO it's premature to document TypedObjects. I think TypedObjects are coming back, but initially to support WebAssembly's interaction with JS, and I would expect the TypedObjects' form to be slightly different from what we have now, more suited to that purpose.

So we may look forward to an eventual revised TC39 proposal for TypedObject, one that explicitly considers interoperability with WebAssembly. But that will probably take a long time. Hopefully someone will write a strawman proposal/polyfill soon.

Thanks, that's really useful info :)

Yeah it's weird. I remember hearing a lot about it a couple years back, and when SpiderMonkey implemented in Firefox it was a noticeable change, largely because we used to call one our hidden type structures "TypeObjects", and that was super confusing when there was a language construct called "TypedObjects", so we renamed our TypeObjects to "ObjectGroup".

Seemed like a really nice proposal for procedural construction of typed views into ArrayBuffers, and perplexing that talk of it seems to have died down...

I haven't looked into it too much, my only experiments were really around DOM manipulation which incurred a huge slowdown.

Sure, but you can't avoid that slowdown by compiling your TypeScript to wasm, can you? DOM is a platform API, and you only get to interact with it in the way the platform allows you to.

That's right. So WASM is only a benefit if you're not doing anything with the DOM.

I see the main use cases outside of games will be intensive computing tasks. For instance Glimmer/Ember could run it's VM on a different thread using WebWorkers and WASM, the same could go for React and it's virtual dom.

Right now, one of the projects I'm working on calls a wasm function which returns a pointer. I then do a lookup in the wasm buffer at the address specified by the pointer and pull out a few numbers with a float64array constructor. Is that an expensive operation?

It's probably best to keep a Float64Array view into the ArrayBuffer around, and use that repeatedly instead of constructing a fresh one each time.

The interpreters and baseline JITs will always construct the object because they can't inline and they don't do whole-method analysis.. and the heavyweight JITs _probably would_ inline the constructor, then notice that the constructed array does not escape, then scalarize the whole thing down to a single read...

but hey, why work the optimizer so hard when you can just make life easy for it and do a single allocation up front, and it runs fast in all performance tiers, and performance isn't predicated on a particular optimization strategy being utilized.

Thanks for the advice, very helpful.

You should ask the profiler.