Hacker News new | ask | show | jobs
by benterix 66 days ago
> JIT warmup is real. The first call to any method pays the compilation cost. In a database engine, the first transaction after startup shouldn’t be 100x slower than the steady state.

Correct me if I'm wrong but isn't it what aot was supposed to solve?

3 comments

In the section “Hardware-accelerated WAL checksums” he explains how the JIT compiles away the hardware support stuff depending on the exact capabilities of the system its on. With AOT you don’t get this - it’s way more coarse like x64 vs ARM
AOT is a little fussy in real-world usage particularly for things like reflection. You can probably force it to work but it may make your code much uglier.

Span<T> is more important for performance TBH JIT warmup isn't a huge issue for a long-running process

    > ...but it may make your code much uglier
Flip side is that if you use more source generation, it may end up making the code more terse/"prettier" where it matters and avoid the reflection hit.

AI agents seem fairly good at generating source generators so there doesn't seem to be a reason to not use them.

With UnsafeAccessor you can often avoid reflection.
What's fussy about AOT and reflection?
Only a subset of reflection is actually AoT safe, and you can run into issues like "the method you wanted to call wasn't statically referenced anywhere, so there is no compiled implementation of it".
That's due to trimming which can be also be enabled for self-contained builds that use JIT compilation. Trimming is mandatory for AOT though. But you can use annotations to prevent trimming of specific thing.

AOT doesn't support generating new executable code at runtime (Reflection.Emit), like you can do in JIT mode.

As the sibling comment says, it's an effect of trimming which you get even without AOT.
Eh, I don't see that as a huge deal because the first thing the DB has to do is warm up the disk cache, at least for the indexes. Of course the first call is slow.