5 ms·

BTW, if there is anyway that I can get Clojure startup time below 0.1s (actually, until 0.2s wouldn't be so bad, but this is my limit) that doesn't involve some

by m45t3r 7y ago

BTW, if there is anyway that I can get Clojure startup time below 0.1s (actually, until 0.2s wouldn't be so bad, but this is my limit) that doesn't involve something like a daemon running I would be all ears. I would really like "real" Clojure in this case (i.e.: not ClojureScript), since the ecosystem from Clojure is much better.

novok 7y ago
Probably not using clojure and using another lisp with a good startup time.
deckiedan 7y ago
https://planck-repl.org/ https://planck-repl.org/ Might help? Clojurescript, but fast start up at least...
- m45t3r 7y ago
  Planck/Lumo for actual projects are really slow and I don't know why (0.5s of startup time). For some reason, the REPL is fast, and I didn't investigate why REPL is fast and an actual project is slow.
lispm 7y ago
Other options like SBCL would allow this easily: $ echo "(format t \"Hello\!~%\")" | cat - > /tmp/test.lisp $ time sbcl --script /tmp/test.lisp Hello! real 0m0.014s Executables are easily created, though they are not small in SBCL. $ sbcl This is SBCL 1.5.9, an implementation of ANSI Common Lisp. More information about SBCL is available at <http://www.sbcl.org/>. SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. * (sb-ext:save-lisp-and-die "howfast" :toplevel (lambda () (format t "Hello!~%")) :executable t) [undoing binding stack and other enclosing state... done] [performing final GC... done] [defragmenting immobile space... (fin,inst,fdefn,code,sym)=1026+935+18027+18435+25326... done] [saving current Lisp image into howfast: writing 0 bytes from the read-only space at 0x20000000 writing 432 bytes from the static space at 0x20100000 writing 26804224 bytes from the dynamic space at 0x1000000000 writing 1990656 bytes from the immobile space at 0x20300000 writing 11935744 bytes from the immobile space at 0x21b00000 done] $ time ./howfast Hello! real 0m0.016s
jonahbenton 7y ago
Did Graal not work because of the limitations in the AOT compiler? I haven't spent a lot of time with it but the few experiments for e.g. little command line utils yield startup indistinguishable from C or Go apps. (Compilation time required by graal still completely non-competitive but could potential work as a packaging step...)
- m45t3r 7y ago
  Yeah. When you start anything remotely complex with GraalVM it starts to break, i.e.: anything related to eval (and this wasn't my code actually, however a good part of Clojure ecosystem depends on eval).

by m45t3r 7y ago

novok 7y ago

Probably not using clojure and using another lisp with a good startup time.

deckiedan 7y ago

https://planck-repl.org/ https://planck-repl.org/ Might help? Clojurescript, but fast start up at least...

m45t3r 7y ago
Planck/Lumo for actual projects are really slow and I don't know why (0.5s of startup time). For some reason, the REPL is fast, and I didn't investigate why REPL is fast and an actual project is slow.

lispm 7y ago

Other options like SBCL would allow this easily: $ echo "(format t \"Hello\!~%\")" | cat - > /tmp/test.lisp $ time sbcl --script /tmp/test.lisp Hello! real 0m0.014s Executables are easily created, though they are not small in SBCL. $ sbcl This is SBCL 1.5.9, an implementation of ANSI Common Lisp. More information about SBCL is available at <http://www.sbcl.org/>. SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. * (sb-ext:save-lisp-and-die "howfast" :toplevel (lambda () (format t "Hello!~%")) :executable t) [undoing binding stack and other enclosing state... done] [performing final GC... done] [defragmenting immobile space... (fin,inst,fdefn,code,sym)=1026+935+18027+18435+25326... done] [saving current Lisp image into howfast: writing 0 bytes from the read-only space at 0x20000000 writing 432 bytes from the static space at 0x20100000 writing 26804224 bytes from the dynamic space at 0x1000000000 writing 1990656 bytes from the immobile space at 0x20300000 writing 11935744 bytes from the immobile space at 0x21b00000 done] $ time ./howfast Hello! real 0m0.016s

jonahbenton 7y ago

Did Graal not work because of the limitations in the AOT compiler? I haven't spent a lot of time with it but the few experiments for e.g. little command line utils yield startup indistinguishable from C or Go apps. (Compilation time required by graal still completely non-competitive but could potential work as a packaging step...)

m45t3r 7y ago
Yeah. When you start anything remotely complex with GraalVM it starts to break, i.e.: anything related to eval (and this wasn't my code actually, however a good part of Clojure ecosystem depends on eval).