Brian Teague (Jun 24 2024 at 20:19): Brian Teague (Jun 24 2024 at 20:19):Just curious about the performance of ROC REPL vs compiled binary for long running processes.
If we ignore startup time for parsing the syntax, and assumed the AST was cached in memory, how would the ROC REPL compare to the compiled binary in performance? Somewhere I think I saw ROC doesn't really do garbage collection, and instead uses reference counting?
Just curios how much faster / slower ROC would be as an interpreted language.
Sam Mohr (Jun 24 2024 at 20:25):Not really answering your question per se, but running Roc compiled to WASM through wasmer or wasmtime would probably have pretty good performance (if 2 or 3 times slower than native is okay with you), especially since most of them have a JIT
Sam Mohr (Jun 24 2024 at 20:27):We can try benchmarking, but I expect the REPL performance would be pretty poor compared to other interpretted languages. The REPL is just a "dumb" interpretter, it doesn't do anything to improve the performance because code that needs to run quickly uses dev mode or release mode, both of which compile to native
Sam Mohr (Jun 24 2024 at 20:27):Whereas something like Python does a lot of stuff under the hood to translate code via JIT to make dynamic code faster because that's the only way to run Python code, so it has to be optimized
Sam Mohr (Jun 24 2024 at 20:29):And yes, Roc uses reference counting via the Perceus paper like Koka, the effect handler language. You can see Koka's explanation of why they do it here, which is the same reason why we do it.
Sam Mohr (Jun 24 2024 at 20:30):In short, reference counting means no runtime (a.k.a. a garbage collector running in another thread), but still (pretty) good performance
Brian Teague (Jun 24 2024 at 20:34):So, a lot of optimizations would be needed to get the REPL closer to binary performance.
Sam Mohr (Jun 24 2024 at 20:37):We could optimize the code (a low effort way would be to compile every time to a dev build), but then the repl is slower to respond with an answer, so it's usually better to have the repl run slowly but respond quickly so that the user experience is good
Notification Bot (Jun 24 2024 at 20:49):Brian Teague has marked this topic as resolved.
Richard Feldman (Jun 24 2024 at 21:54):Brian Teague said:
Just curious about the performance of ROC REPL vs compiled binary for long running processes.
If we ignore startup time for parsing the syntax, and assumed the AST was cached in memory, how would the ROC REPL compare to the compiled binary in performance? Somewhere I think I saw ROC doesn't really do garbage collection, and instead uses reference counting?
Just curios how much faster / slower ROC would be as an interpreted language.
roc repl actually currently generates a binary and then runs it :big_smile:
Richard Feldman (Jun 24 2024 at 21:55):we don't currently have an interpreter
Richard Feldman (Jun 24 2024 at 21:56):so what these commands do is:
roc build builds a binaryroc run builds a binary and then runs itroc repl builds a binary based on your input, runs it, and prints the output Richard Feldman (Jun 24 2024 at 21:56):the main reason the performance would be worse is that there's (currently) no roc repl --optimize
Richard Feldman (Jun 24 2024 at 21:57):so you're never getting optimizations in the repl, whereas if you do roc build --optimize or roc run --optimize the compiled binary will have optimizations, whereas roc repl never does them
Sam Mohr (Jun 24 2024 at 21:59):Thanks for clarifying! Apologies for the mislead :sweat_smile:
Richard Feldman (Jun 24 2024 at 21:59):but we've actually talked about creating an interpreter specifically for compile-time evaluation of top-level constants
Richard Feldman (Jun 24 2024 at 21:59):I forget what thread that was on
Sam Mohr (Jun 24 2024 at 22:00):Here's one such discussion: https://roc.zulipchat.com/#narrow/stream/304641-ideas/topic/Compile.20time.20computation/near/258843147
Last updated: Jul 26 2025 at 12:14 UTC