Drewry Pope (Nov 16 2025 at 06:11): Drewry Pope (Nov 16 2025 at 06:11):How fast is roc? Can I use it for a game loop itself? Do I have to pass all data as values to the function, or is there a way for the platform to manage pointers that the roc code calls? Use case I'm thinking is that I could give the game state to every loop, but I imagine that copying the values down wouldn't be ideal. If I could read values out of a struct of arrays I imagine it could be fast, but I wondered how I would even be able to do that, would I need like, to implement like read(path, index) and then pass back/forward for each read? Maybe read(path, start, count) and return an array in some contexts? I worry that might be slow with all the extra functions, or maybe not? Maybe it's the kind of thing that a smart compiler could inline? I'd guess writing would have similar difficulties. Being lazy coder, I'd just want to pass a struct in at the start and then return a new /modified/the-same struct at bottom.
My understanding is that roc compiles down to be roughly as fast as any pure function in a statically compiled language, but there may be added overhead for certain scenarios like above where the need for 'effects' causes a larger amount of functions and deeper stacks to compensate for the overhead provided by the safety guarantees of roc.
Brendan Hansknecht (Nov 16 2025 at 06:21):How fast is roc?
Think in the same ballpark as go when used correctly. So quite fast but not the fastest possible thing due to memory management.
Can I use it for a game loop itself?
You definitely could.
Do I have to pass all data as values to the function, or is there a way for the platform to manage pointers that the roc code calls?
You could do either. You could pass in a record with all of the state (as long as the state is store in a roc friendly format (like using RocStr for string data). Or you could pass an opaque pointer and require roc to use an effect to extract the data.
to implement like read(path, index) and then pass back/forward for each read? Maybe read(path, start, count) and return an array in some contexts?
Yeah, those would both be options.
I worry that might be slow with all the extra functions, or maybe not?
The cost will roughly be the same as calling a virtual function on a class in C++. So definitely not zero, but for most use cases, not something you need to worry about.
Being lazy coder, I'd just want to pass a struct in at the start and then return a new /modified/the-same struct at bottom.
Definitely doable if the platform can represent its state in Roc types. You may have to be a little careful around immutability semantics, but totally should be workable.
My understanding is that roc compiles down to be roughly as fast as any pure function in a statically compiled language
Yeah... only extra context is with reference counting and potentially with more cost due to immutability by default.
'effects' causes a larger amount of functions and deeper stacks
The biggest loss is really that the platform and the application are not a single compilation unit. As such, there is no inlining between the two. Even a C/C++/rust application without LTO will actually hit many similar inlining issues.
Drewry Pope (Nov 16 2025 at 06:26):ohhh okay thank you very much. I'll try to think about this.
Last updated: Nov 28 2025 at 12:16 UTC