(to_lisp);
(loop for i below 1000000 count t) takes 0.34 seconds on my system with vanilla maxima (on gcl). In the browser it takes about 7 seconds, so it must be a factor of 21 in computer time. Using sbcl outside maxima it takes 0.002 seconds. So one can get some idea about performance.
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.
Web version of ecl when compiler is invoked at runtime, uses one-pass bytecodes compiler, so things tend to lack optimization unless compiled beforehand.
It feels faster than the other web-hosted maxima instances out there and if you take into account the cost of installing common lisp and maxima (I only need to use this about twice a year so I don't keep them live), it can be much faster than a local instance.
Perhaps it could be combined with J (array language), like in the playground https://code.jsoftware.com/wiki/Playground that is using webassembly
It seems to work very well locally without connection to the web.