Static Allocation for Compilers
Posted14 days agoActive7 days ago
matklad.github.ioTech Discussionstory
informativepositive
Debate
20/100
Code MigrationMemory LocalityOptimization Techniques
Key topics
Code Migration
Memory Locality
Optimization Techniques
Discussion Activity
Light discussionFirst comment
9h
Peak period
4
144-156h
Avg / period
2.2
Key moments
- 01Story posted
Dec 23, 2025 at 5:53 PM EST
14 days ago
Step 01 - 02First comment
Dec 24, 2025 at 2:52 AM EST
9h after posting
Step 02 - 03Peak activity
4 comments in 144-156h
Hottest window of the conversation
Step 03 - 04Latest activity
Dec 30, 2025 at 1:03 PM EST
7 days ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 46370446Type: storyLast synced: 12/30/2025, 12:35:28 AM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
Static memory allocation requires hardcoding an upper limit of size of everything. For example, if you limit each string to be at most 256 bytes, then a string with only 10 bytes will waste 246 bytes of memory.
If you limit string length to 32 bytes it will waste fewer memory but when a string longer than 32 bytes comes it cannot handle.
No? Unless you limit each string to be exactly 256 bytes but that's silly.
> If you limit string length to 32 bytes it will waste fewer memory but when a string longer than 32 bytes comes it cannot handle.
Not necessarily. The early compilers/linkers routinely did "only the first 6/8 letters of an identifier are meaningful" schtick: the rest was simply discarded.
Even if you needed to hardcode upper size limits, which your compiler already does to some extent (the C/C++ standards anticipate this by setting minimum limits for certain things like string length), you wouldn't actually pay the full price on most systems because of overcommit. There are other downsides to this depending on implementation details like how you reclaim memory and spawn compiler processes, so I'm not suggesting it as a good idea. It's just possible.
I don't follow. He has just said that although the size of the arena is finite, the input and output are unbounded, and the compiler does its work by processing "a sequence of chunks" (i.e. those things that will fit into the finitely sized arena). That's not "O(1) intermediate processing artifacts". It's still O(n).
> [...] can clarify compiler’s architecture, and I won’t be too surprised if O(1) processing in compilers would lead to simpler code
This doesn't seem like an intuitive conclusion at all. There's more recordkeeping needed now, and more machinery in need of being implemented, which should be expected to make for something that is neither simple nor easy.
We haven't even gotten around to addressing how "statically allocating" a fixed size arena that your program necessarily subdivides into pieces (before moving onto the next chunk and doing the same) is just "dynamic allocation with extra steps". (If you want or just think that it would be neat to write/control your own allocator, then fine, but... say that.)
C/C++ compilers can get huge compile time speed ups by compiling translation units as Unity files. For my work AAA game engine, a compiler can use 8GB+ per unit.
Just splitting up code might allow the compiler to use less memory, but compile time will increase hugely.
IIRC, Unix's original as works that way: during assembly, the text and data sections are written into separate temporary files, and then they are merged together into the a.out. And yes, it's slow.
However, breaking up huge functions (or skipping optimizations on them) will lead to missed opportunities. And LTO-style optimizations, where the entire program is taken into account, can be very important as well (as a concrete example, we see huge benefits from doing that in wasm-opt for Wasm GC).
Still, it's a nice idea, and maybe it can make 80% of compiler passes a lot faster!