I went kinda nuts on yesterday's #adventofcode trying to optimize my #Ruby implementation. The resulting code is nothing special, but here it is, for reference: https://codeberg.org/der-scheme/adventofcode.rb/src/branch/main/2025/08
I consistently achieve sub 2.5 seconds with #YJIT for all four (both parts on both input and test input) runs, including I/O and all the process spawning stuff, measured by `time ./test`. No JIT is about 25โ30% slower. I have no idea how fast this is, but I'm stating it for transparency.
I consider myself a smooth-brain, but here's what I believe to have learned (some very obvious, others not so much):
- Even if you don't care about your return values (discarding them), YJIT does. So if the return value is irrelevant, return a predictable value; self is a good choice. This is consistent with YJIT's documented behavior.
- There's a tiny overhead in splatting, so it's faster to be explicit.
- There seems to be some overhead in the creation of local variables. Sometimes it's faster calling a reader method multiple times.
- While structs (Struct, not Data, although they share most of the implementation) can be slightly slower than trivial wrapper classes, I found a case where a struct with a single field resulted in a 15% overall runtime boost compared to the equivalent class. It's no longer in the code base, though, because:
- Oftentimes, shoving everything into an array to deal with later is faster than dealing with it early.
- There seems to be no performance gain in freezing. I attempted freezing an object in the constructor hoping YJIT would maybe inline instance variable access, but this resulted in an overall 10% performance drop through this single line change. However, the necessary code changes resulted in speedups in other places, so the work was still worth it.
- Sometimes arrays are faster, sometimes enumerators are faster, for the exact same functionality.
- `def some_size = some&.size || 0` seems faster than the verbose alternative. Maybe YJIT can optimize operators better than branches?
- There's a bunch of stuff I didn't try, like the C-like implementations you can find published all over the internet. If I wanted to write fast but unreadable code, I'd use FFI and C.
- Git commit makes your code run slower. I assume there's some FS weirdness going on which is triggered by committing, like maybe a cache reset.
N-gated Hacker News
news_kr
bot
