Web Embeddable Common Lisp

When executing (time (loop for i below (expt 10 8) count t)) it takes a long time, sbcl takes less than a second on this. So not useful when speed is required. More: (time (loop for i below 1000000 count t) takes 7 seconds on my computer, so counting to (exp 10 8) would take 700 seconds, and sbcl do that in 0.1 seconds, so in this example the ratio is 7000 times slower than sbcl.

Bytecodes compiler used in this build from repl is one-pass with very little optimizations, so it is not surprising. Natively compiled code is much faster.

Should it be possible to implement an optimization compiler? so that compiling the code in the web page produces results similar to ECL or sbcl?

With enough code - yes. But not right now. You may precompile to native though.

In SLip: https://lisperator.net/s/slip/

    SL-USER> (time (loop for i below (expt 10 8) count t))
    Evaluation time: 19376ms
    100000000

    SL-USER> (time (loop for i below 1000000 count t))
    Evaluation time: 272ms
    1000000

    SL-USER> (defun fib (n) (if (< n 2) n (+ (fib (- n 1)) (fib (- n 2)))))
    #'FIB
    SL-USER> (time (fib 32))
    Evaluation time: 1601ms
    2178309

These timings are in Firefox; Chromium is almost 2x faster. Also, it doesn't completely freeze the browser in the mean time (we have green threads).

I used to think it's quite slow, but somehow it's much faster than any other posted here. The only Lisp in browser I know to beat SLip (by a large margin) is JSCL, which compiles to JS.

Both slip and jscl takes the same time in my computer: 63 seconds to run the loop.

Hm, you're right, JSCL seems abnormally slow on this loop (27.5 sec here). SLip consistently takes 19.3 sec. My CPU is rather beefy (Ryzen 9 HX 370). What's your hardware and browser?

But JSCL is much faster on the fib example, that's why I thought it should be generally faster. After all, it compiles to JS.

I can see what happens there in JSCL.. I took a look at

    (disassemble (lambda () (loop for i below (expt 10 8) count t)))

Seems TAGBODY is compiled into a while(true) which sets an exception handler on each iteration. (and then, LOOP macroexpands into a TAGBODY). I don't think there's a better way to do it, BTW — JS is simply not a friendly compilation target. But `try` on each iteration is quite costly, that's most probably the bottleneck here.