Apart from the restriction to bytecode interpretation already mentioned, one reason for the slowness is that the sort of C with garbage collection that ECL needs is quite difficult to do in Webassembly. There is no way to scan previous stack frames for pointers in wasm, so all pointers to heap objects (or everything that looks like it might be one) have to be kept around somewhere in the heap where the GC can find them. This is really expensive and slows down the code a lot.
Of course, another approach would be to use the new wasm GC interface. But that requires defining a new ABI for garbage collected C, writing a new backend for LLVM, etc. So that would also be a lot of work to implement. Right now, there just is no efficient way to run programs that depend on bdwgc on wasm.
Of course, another approach would be to use the new wasm GC interface. But that requires defining a new ABI for garbage collected C, writing a new backend for LLVM, etc. So that would also be a lot of work to implement. Right now, there just is no efficient way to run programs that depend on bdwgc on wasm.