Richard Feldman (Aug 04 2026 at 21:39): Richard Feldman (Aug 04 2026 at 21:39):I'd like to get some numbers on what kind of build times people are seeing when building things with Roc.
This is very open-ended! I'm just trying to get a sense of what people are seeing in practice, since I care a lot about build times being fast but since I'm focused on compiler work right now, I don't have a sense of what people are experiencing on their projects. :smile:
Feel free to post any numbers you have in this thread! It's helpful to know if they're cold builds (--no-cache) or rebuilds, and also ideally what system you're running on and what roc version outputs.
Niclas Ahden (Aug 04 2026 at 21:49):Building Joy TodoMVC:
roc build --target=wasm32 --no-cache app.roc
roc build
✓ Resolving Dependencies 484ms
✓ Parsing 8ms
✓ Name Resolution 3ms
✓ Type Inference 50ms
✓ Compile-Time Evaluation 3ms
Monotype Lowering 1ms
LIR Generation 0ms
LIR Passes 0ms
ARC 0ms
Static Data 0ms
x64 Instruction Generation 0ms
Execution 1ms
Store Results 0ms
✓ Monotype Setup 0ms
✓ Root + Wrapper Setup 0ms
✓ Specialization Lookup + Reservation 1ms
✓ Dispatch Evidence 5ms
✓ Body Graph Setup 6ms
✓ Body Traversal + Binding 58ms
✓ Body Type Graph 0ms
✓ Body Call Dispatch 0ms
✓ Body Draft IR Construction 0ms
✓ Body Reachability + Proofs 0ms
✓ Body Source Mapping 0ms
✓ Body Local Procedure Context 0ms
✓ Body Sealing + Commit 5ms
✓ Procedure Completion 0ms
✓ Layout Requests 0ms
✓ Static Data Requests 0ms
✓ Monotype Finalization 0ms
✓ Closure Lifting 0ms
✓ SpecConstr 15ms
✓ Lambda-Set Solving 7ms
✓ Inline Planning 0ms
✓ LIR Generation 1ms
✓ LIR Passes 2ms
✓ ARC 1ms
✓ Static Data 0ms
✓ LLVM IR Generation 6ms
✓ LLVM Optimize + Emit 406ms
✓ Linking 7ms
roc build 1.1s
0 errors and 0 warnings found in 1.1s while successfully building:
app.wasm
Edited source with cache:
roc build --target=wasm32 app.roc
0 errors and 0 warnings found in 552ms while successfully building:
app.wasm
NixOS, x86, AMD 9950X, Roc 94cbed386c51a8739ced3be76e7ab7b84dd22852.
Jasper Woudenberg (Aug 04 2026 at 22:06):Check and test times too? Test times in particular I noticed are a bit on the slower side, especially for the relatively small number and libraries I run these for.
Using Roc build from nix flake, revision 38c51448b837ae3fd1b606805ef2b254b196596e
# roc check --no-cache rvn/main.roc
No errors found in 627ms for main.roc
# roc test --no-cache rvn/main.roc
All (82) tests passed in 9832.2 ms.
# roc check --no-cache gregorian/main.roc
No errors found in 501ms for gregorian/main.roc
# roc test --no-cache gregorian/main.roc
All (48) tests passed in 4508.5 ms.
those test times are very surprising! I'll look into that, thanks :+1:
Luke Boswell (Aug 04 2026 at 22:23):Linux x64 AMD Ryzen 7 9700X 8-Core Processor
Screwbot on a gaming rig
Luke Boswell (Aug 04 2026 at 22:27):Makes me think we should add a flag for build times in a machine readable format like JSON
Karl (Aug 05 2026 at 00:34):| $ roc build --output="./bt" --opt=speed apps/burntranscribe/main.roc
roc build
✓ Resolving Dependencies 3ms
✓ Parsing 9ms
✓ Name Resolution 18ms
✓ Type Inference 295ms
✓ Compile-Time Evaluation 1.2s
Monotype Lowering 1.1s
LIR Generation 78ms
LIR Passes 2ms
ARC 3ms
Static Data 1ms
arm64 Instruction Generation 11ms
Execution 11ms
Store Results 1ms
✓ Monotype Setup 0ms
✓ Root + Wrapper Setup 0ms
✓ Specialization Lookup + Reservation 8ms
✓ Dispatch Evidence 0ms
✓ Body Graph Setup 37ms
✓ Body Traversal + Binding 785ms
✓ Body Type Graph 0ms
✓ Body Call Dispatch 0ms
✓ Body Draft IR Construction 0ms
✓ Body Reachability + Proofs 0ms
✓ Body Source Mapping 0ms
✓ Body Local Procedure Context 0ms
✓ Body Sealing + Commit 590ms
✓ Procedure Completion 2ms
✓ Layout Requests 0ms
✓ Static Data Requests 0ms
✓ Monotype Finalization 0ms
✓ Closure Lifting 1ms
✓ SpecConstr 854ms
✓ Lambda-Set Solving 209ms
✓ Inline Planning 0ms
✓ LIR Generation 27ms
✓ LIR Passes 287ms
✓ ARC 72ms
✓ Static Data 0ms
✓ LLVM IR Generation 1.4s
✓ LLVM Optimize + Emit 10.0s
✓ Linking 285ms
roc build 15.9s
Same timings with --no-cache on the second run. App is 3.5k LoC, Platform is 3k LoC Roc + 71k LoC Rust, Macbook M1
Karl (Aug 05 2026 at 00:39):$ roc build --no-cache --output="./bt" --opt=speed examples/realworld/main.roc
roc build
✓ Resolving Dependencies 3ms
✓ Parsing 6ms
✓ Name Resolution 8ms
✓ Type Inference 105ms
✓ Compile-Time Evaluation 12ms
Monotype Lowering 5ms
LIR Generation 2ms
LIR Passes 0ms
ARC 1ms
Static Data 0ms
arm64 Instruction Generation 1ms
Execution 2ms
Store Results 0ms
✓ Monotype Setup 0ms
✓ Root + Wrapper Setup 0ms
✓ Specialization Lookup + Reservation 3ms
✓ Dispatch Evidence 4ms
✓ Body Graph Setup 12ms
✓ Body Traversal + Binding 258ms
✓ Body Type Graph 0ms
✓ Body Call Dispatch 0ms
✓ Body Draft IR Construction 0ms
✓ Body Reachability + Proofs 0ms
✓ Body Source Mapping 0ms
✓ Body Local Procedure Context 0ms
✓ Body Sealing + Commit 43ms
✓ Procedure Completion 1ms
✓ Layout Requests 0ms
✓ Static Data Requests 0ms
✓ Monotype Finalization 0ms
✓ Closure Lifting 2ms
✓ SpecConstr 54ms
✓ Lambda-Set Solving 56ms
✓ Inline Planning 0ms
✓ LIR Generation 137ms
✓ LIR Passes 92ms
✓ ARC 27ms
✓ Static Data 1ms
✓ LLVM IR Generation 641ms
✓ LLVM Optimize + Emit 5.1s
✓ Linking 96ms
roc build 6.6s
Example is 1.2k LoC, platform is 1.3k LoC
Richard Feldman (Aug 05 2026 at 00:51):@Karl @Jasper Woudenberg @Niclas Ahden out of curiosity, do you normally use roc build when building for development? or do you use roc without build to just build and run? or something else?
Karl (Aug 05 2026 at 00:56):I've been using the CLI as listed without the --no-cache just because 5-15s doesn't really bother me (Rust...) but I mean to switch over to just running it in roc for the hot reload. I haven't done it yet because it's not picking up the changes. I think it's the main loop not terminating and it'll work if I tweak it but I haven't gotten around to it. I've been very platform focused on both projects so I haven't been doing a lot of app work and that would change the motivation.
The 7min timing for rebuilding the Roc compiler (which is like 5:50 LLVM) does annoy me but that's a matter of Apple silicon getting zig incremental builds.
Richard Feldman (Aug 05 2026 at 01:10):ok maybe we should change the default...roc build is actually doing optimized builds, which is not necessary - if you do roc build --opt=dev it will not use LLVM and will be way faster
Richard Feldman (Aug 05 2026 at 01:11):the reasoning for making --opt=speed the default for roc build was the assumption that roc without build would be used for normal development, and once you wanted to do roc build it was probably because you were ready to actually release, so it would be helpful to make it so you couldn't forget to do --opt=speed but maybe that's actually not the right default after all :sweat_smile:
Karl (Aug 05 2026 at 01:17):I think that was the right decision. I do it this way because I run compiled languages in release unless it's slow enough to really disrupt things and I'm not annoyed to the point of making the change. As mentioned, I do plan on switching over to the base roc for dev once I figure out why the hot reload isn't getting picked up on my platforms which is my issue and not roc.
Richard Feldman (Aug 05 2026 at 01:35):oh you shouldn't need to do anything
Richard Feldman (Aug 05 2026 at 01:37):it might be the way it's structured though - basically what happens is that when roc detects a change to the entrypoint function(s) your app provides to the platform, it just swaps them out for the new ones so that the next time the platform calls them, it'll get the new ones
Richard Feldman (Aug 05 2026 at 01:37):so if you're not seeing any hot loading, I'm guessing it's because the platform only calls those functions once on startup?
Karl (Aug 05 2026 at 01:38):They're both on an event loop so I think I have to trampoline the loop or something.
Richard Feldman (Aug 05 2026 at 03:17):does the event loop call them repeatedly? :thinking:
Jasper Woudenberg (Aug 05 2026 at 07:11):Richard Feldman said:
Karl Jasper Woudenberg Niclas Ahden out of curiosity, do you normally use
roc buildwhen building for development? or do you userocwithoutbuildto just build and run? or something else?
I haven't used roc build much yet because I've been working on libraries. Now I'm back to working on my platform jay, there I don't expect to use roc build much either because the nature of jay is that you run it as a script.
Niclas Ahden (Aug 05 2026 at 08:15):Richard Feldman said:
the reasoning for making
--opt=speedthe default forroc buildwas the assumption thatrocwithoutbuildwould be used for normal development, and once you wanted to doroc buildit was probably because you were ready to actually release, so it would be helpful to make it so you couldn't forget to do--opt=speedbut maybe that's actually not the right default after all :sweat_smile:
I’m using it exactly as you describe, so I’m happy with the current situation :ok:
Richard Feldman (Aug 05 2026 at 12:18):ok then I'll leave it as-is for now!
Niclas Ahden (Aug 05 2026 at 12:35):Tested on a Mac:
MacBook Pro M1 Max: Full TodoMVC build
MacBook Pro M1 Max: build --watch on a small change
Richard Feldman (Aug 05 2026 at 12:39):nice!
Bryce Miller (Aug 06 2026 at 01:03):Here's an example from roc-pg:
Roc version: nightly-2026-August-05-24f0b47
Source: https://github.com/sandprickle/roc-pg/blob/migrate-zig-compiler/examples/query.roc
MacBook Air M1
HyperFine output
roc build output
Dev build is just a hair over 700ms
Krzysztof Skowronek (Aug 13 2026 at 21:21):I built the robot arm example on Windows on Thinkpad T14 with Ryzen 7 PRO 4750U
38.7s for --no-cache
31.4s with cache
opt=dev 12s, but it crashes
also, the program itself takes 120mb of RAM, I don't know if that's a lot to be honest, but it seems quite a bit for a raylib app. When I wiggle the arm fast, it grows to above 200 sometimes. I wanted to take a screenshot, but now it just hovers around 130-140 no matter what I do :)
Krzysztof Skowronek (Aug 13 2026 at 21:22):so I don't think that the cache is doing much on Windows, and the compile times are a bit long for my taste - I hope that's just a quirk of the almost numbered version :)
Krzysztof Skowronek (Aug 13 2026 at 21:33):https://github.com/lukewilliamboswell/terrocotta/blob/screwbot-showcase/examples/counter.roc
roc --opt=dev .\examples\counter.roc takes 3s, almost 18s for the speed build
Krzysztof Skowronek (Aug 13 2026 at 21:35):also, the counter app itself uses 70mb of ram, which is more in line of what I would expect - C# and WPF app with a counter would probably stay under 30mb though
Luke Boswell (Aug 13 2026 at 21:41):Thank you @Krzysztof Skowronek would you mind sharing roc version
Krzysztof Skowronek (Aug 13 2026 at 21:45):PS C:\Users\KrzysztofSkowronek> roc --version
Roc compiler version nightly-2026-08-12-606470f
counter.cs
counter_winforms.cs
out of curiosity I made a counter example in C#, if you want you can run it with dotnet run -c release counter.cs (only on Windows)
wpf version uses 60mb, winforms is 10mb :D
Richard Feldman (Aug 13 2026 at 23:14):thanks, I'll take a look at these!
Richard Feldman (Aug 13 2026 at 23:17):I'm surprised lss and monotype lowering are taking so long. The linking thing should be an easy fix.
Aurélien Geron (Aug 16 2026 at 09:31):FWIW, here's the execution time of 110 exercises using roc test --opt=dev versus roc test --opt=speed. I had to use a log-log scale because the timings vary wildly. There are a few outliers on both sides:
Since I'm using roc test, this includes both the build time and the execution time.
Richard Feldman (Aug 16 2026 at 11:20):which ones are the outliers? I can look at those first
Aurélien Geron (Aug 16 2026 at 20:24):Thanks @Richard Feldman . Here are the exercises that take over 1 second with --opt=speed and that are over 20 times slower than with --opt=dev:
pov: dev 36 ms -> speed 85,801 ms (manipulates a binary tree)gigasecond: dev 500 ms -> speed 12,796 ms (uses the isodate library)meetup: dev 414 ms -> speed 11,024 ms (uses the isodate library)micro-blog: dev 324 ms -> speed 6,874 ms (uses the unicode library)two-bucket: dev 63 ms -> speed 1,315 ms (includes a recursive search)affine-cipher: dev 39 ms -> speed 1,825 msforth: dev 50 ms -> speed 1,158 ms (includes a recursive search)go-counting: dev 48 ms -> speed 1,070 ms (includes a recursive search)Note: the exercises that are much slower with --opt=dev than with --opt=speed are the compute-heavy exercises, so it makes sense, no issue there.
Lastly, there are two exercises that work fine with --opt=dev but crash with --opt=speed: robot-name and pov.
Richard Feldman (Aug 16 2026 at 20:26):I'm curious about the compute-heavy ones too, actually!
Aurélien Geron (Aug 16 2026 at 20:28):Sure, here they are:
alphametics: dev 10,506 ms -> speed 1,221 msperfect-numbers: dev 7,044 ms -> speed 649 msnth-prime: dev 4,770 ms -> speed 659 mssum-of-multiples: dev 3,921 ms -> speed 691 ms Aurélien Geron (Aug 16 2026 at 20:34):Here's the full table if you're interested:
dev_speed_comparison.tsv
Richard Feldman (Aug 16 2026 at 21:11):nice, thank you! I'm gonna dig into these and see what room for improvement there is
Richard Feldman (Aug 16 2026 at 21:11):if you're curious to try it, the --specialize=no flag is an experimental thing that may help with roc test times specifically
Richard Feldman (Aug 16 2026 at 21:12):might also make them worse right now though, not sure :laughing:
Aurélien Geron (Aug 16 2026 at 21:55):I tried --specialize=no with roc test, but I got a lot of crashes, and a few freezes:
accumulate, acronym, affine-cipher, all-your-base, allergies, alphametics, anagram, armstrong-numbers, atbash-cipher, binary, binary-search, binary-search-tree, bob, bowling, change, circular-buffer, clock, collatz-conjecture, complex-numbers, connect, crypto-square, custom-set, darts, diamond, difference-of-squares, dominoes, eliuds-eggs, error-handling, etl, flatten-array, flower-field, food-chain, forth, gigasecond, go-counting, grains, grep, hamming, hello-world, hexadecimal, high-scores, house, isbn-verifier, isogram, killer-sudoku-helper, kindergarten-garden, knapsack, largest-series-product, leap, list-ops, luhn, matching-brackets, matrix, meetup, micro-blog, minesweeper, nth-prime, nucleotide-count, ocr-numbers, octal, palindrome-products, pangram, pascals-triangle, perfect-numbers, phone-number, pig-latin, poker, pov, prime-factors, protein-translation, proverb, pythagorean-triplet, queen-attack, rail-fence-cipher, raindrops, rational-numbers, rectangles, resistor-color, resistor-color-duo, rest-api, reverse-string, rna-transcription, robot-name, robot-simulator, roman-numerals, rotational-cipher, run-length-encoding, saddle-points, say, scrabble-score, secret-handshake, series, sgf-parsing, sieve, simple-linked-list, space-age, spiral-matrix, square-root, strain, sublist, sum-of-multiples, tournament, transpose, triangle, two-bucket, two-fer, variable-length-quantity, word-count, word-search, wordy, yacht, zebra-puzzlechange, high-scores, luhn, poker, prime-factors, yachtall-your-base, binary-search, circular-buffer, collatz-conjecture, difference-of-squares, food-chain, grains, hello-world, isogram, knapsack, leap, matrix, proverb, queen-attack, raindrops, resistor-color, resistor-color-duo, say, space-age, square-root, triangle, two-fer, wordy, zebra-puzzle Aurélien Geron (Aug 16 2026 at 21:57):The execution times for the ones that worked are a bit suspicious, with a vast majority equal to 130.1 ms:
Aurélien Geron (Aug 16 2026 at 22:51):One last thing: for two exercises, roc test --opt=speed crashes while roc test --opt=dev works fine. I'm trying to reproduce the issue with a minimal code example, but it's not easy.
Luke Boswell (Aug 17 2026 at 04:05):I've got some really fat apps in the roc-pdf package... I'll do a more structured survey and share the results here.
Luke Boswell (Aug 17 2026 at 05:03):All the results and configuration is in this JSON file, and I included an analysis also from codex
https://gist.github.com/lukewilliamboswell/07b088aebb7d1ec25fa663f0800c06eb
Luke Boswell (Aug 17 2026 at 05:04):This is using yesterday's nightly
Luke Boswell (Aug 17 2026 at 05:58):roc build tests/gate3_pdf_facade_chunks_negative/main.roc --opt=dev
Aurélien Geron (Aug 24 2026 at 02:41):Something is a bit fishy with the speed of roc test --opt=dev. Here's a graph comparing the test time last week (August 16 in NZ) with the test times today (August 24 in NZ) across all Exercism exercises:
Notice that the times are comparable above 100ms (although a bit higher today than last week), but there's no longer any test time below roughly 130ms.
Aurélien Geron (Aug 24 2026 at 02:52):Here's the same graph but with --opt=speed (for both dates).
Edit: I updated the graph because I had made a mistake. Fixed now.
Aurélien Geron (Aug 24 2026 at 02:57):Lastly, here's --opt=dev versus --opt=speed today:
This looks significantly worse for most exercises, except 5.
Luke Boswell (Aug 24 2026 at 03:20):How are you collecting the time, is this time roc test ...?
Luke Boswell (Aug 24 2026 at 03:21):Definitely smells like a regression somewhere is putting a floor on the test time. My guess is we broke the caching for the builtins somehow (totally wild guess)
Aurélien Geron (Aug 24 2026 at 03:35):I'm just grabbing the times displayed in the test outputs, such as: All (14) tests passed in 1032.6 ms.
Luke Boswell (Aug 24 2026 at 03:43):Another example of where we should add that machine readable output flag ... did we ever make a GH Issue for that?
Luke Boswell (Aug 24 2026 at 03:43):I'll have a look
Luke Boswell (Aug 24 2026 at 03:54):Is there a better format for machine readable stats than JSON?
Luke Boswell (Aug 24 2026 at 03:54):Oh ... sqlite3? :grinning_face_with_smiling_eyes:
Luke Boswell (Aug 24 2026 at 03:55):Now we're cooking with gas
Aurélien Geron (Aug 24 2026 at 04:01):Btw, the two exercises that used to crash with --opt=speed but not with --opt=dev now work fine with both. However, the sgf-parsing exercise now causes a segfault when run with --opt=speed, I opened issue #10912.
Luke Boswell (Aug 24 2026 at 04:10):I think my head just exploded with ideas ... I've been sitting on this general theme of a performance observatory and I think we just hit on a goldmine for how to actually do it properly.
Luke Boswell (Aug 24 2026 at 04:12):Like is there any better binary encoding stable widely supported data format than sqlite?
Matthieu Pizenberg (Aug 24 2026 at 09:23):@Luke Boswell sqlite-everything ^^ https://fzakaria.com/2026/08/23/your-executable-is-a-sqlite-database
Luke Boswell (Aug 25 2026 at 11:36):Matthieu Pizenberg said:
Luke Boswell sqlite-everything ^^ https://fzakaria.com/2026/08/23/your-executable-is-a-sqlite-database
Circling back on this here is an idea using sqlite for roc-ray https://github.com/lukewilliamboswell/roc-ray/issues/178
Tobias Steckenborn (Aug 26 2026 at 14:52):mhh what exactly does the "specializing" step survey, so in case it takes quite long, what's the likely root cause to investigate?
Anton (Aug 26 2026 at 15:01):In specialization generic code is transformed into specific faster version(s) based on known information like fixed arguments and known types.
Tobias Steckenborn (Aug 26 2026 at 15:02):guess it running for 14 minutes would indicate something being off that I need to investigate :sweat_smile:
Anton (Aug 26 2026 at 15:02):what's the likely root cause
A bunch of generic functions that get called from a bunch of different paths.
Anton (Aug 26 2026 at 15:03):Are you using the release a compiler or a debug build?
Tobias Steckenborn (Aug 26 2026 at 15:03):nightly-2026-08-13-2fdd90e
Anton (Aug 26 2026 at 15:03):Feel free to toss the source code in an issue, we can minimize and investigate
Tobias Steckenborn (Aug 26 2026 at 15:04):will first try to update and see if I can locate the issue
Anton (Aug 26 2026 at 15:04):Yeah, we've landed a lot of fixes since 08-13
Richard Feldman (Aug 26 2026 at 18:36):yeah 14 minutes is prob some pathological compiler thing that needs to be fixed, not a problem with your code :smile:
Aurélien Geron (Aug 26 2026 at 23:18):It looks like roc test is significantly faster today than 3 days ago with both --opt=speed and --opt=dev:
Aurélien Geron (Aug 26 2026 at 23:19):Side-note: please let me know if these plots are not useful, I don't want to spam everyone. :sweat_smile:
Luke Boswell (Aug 26 2026 at 23:25):I'm loving the plots!
Luke Boswell (Aug 26 2026 at 23:31):Curious that dev has a floor on it? oh that was the 24th version only and we fixed that?
Aurélien Geron (Aug 26 2026 at 23:35):Thanks @Luke Boswell, I'll continue posting those then. :+1:
Yes, the 24th had an issue where the time was at least ~130ms. This has been fixed, apparently.
Luke Boswell (Aug 26 2026 at 23:37):Yeah I saw that fix roll through https://github.com/roc-lang/roc/pull/10916
Richard Feldman (Aug 28 2026 at 01:20):yeah I had something based on your previous plots
Richard Feldman (Aug 28 2026 at 01:20):but I've been moving so I'm very disorganized right now :sweat_smile:
Richard Feldman (Aug 28 2026 at 01:20):I'm not keeping track of what fixes are in what state haha
Niclas Ahden (Aug 28 2026 at 10:51):I'm trying to migrate a large app and found this quadratic behaviour: https://github.com/roc-lang/roc/issues/10978
My server takes 1m 33s to build, so I've been troubleshooting on that. The client hasn't finished after 30 min, so I think there may be more issues lurking, which I'm trying to reduce now!
Niclas Ahden (Aug 28 2026 at 12:54):Troubleshooting the client (wasm) build led me to this:
https://github.com/roc-lang/roc/issues/10979
https://github.com/roc-lang/roc/issues/10980
These two together seems to balloon the wasm size which makes LLVM take way too long (more than 30 min in my case). dev builds give me 100+ MB of wasm, so I technically can ship, but ... maybe, maybe :sweat_smile:
Niclas Ahden (Sep 02 2026 at 18:30):phew! I've been pulling my hair trying to get this app to compile, but it's been hanging in compilation and/or OOM:ing, and the issues were difficult to minimally reproduce. I've finally narrowed down these two culprits :raised_hands:
https://github.com/roc-lang/roc/issues/11072
https://github.com/roc-lang/roc/issues/11073
There may be more hiding in there, but I'm throwing in the diagnostics towel at this point :sweat_smile:
Richard Feldman (Sep 02 2026 at 18:41):wow, thank you for the repros - will be super helpful to fixing! :smiley:
Niclas Ahden (Sep 02 2026 at 18:46):One for Roc and Roc for all! :D
Last updated: Sep 03 2026 at 15:16 UTC