Engineering High-Performance Parsers with Data-Oriented Design

I believe it's an almost-entirely LLM-generated article probably fed that URL as part of the prompt.

+1, this is carbon copy of what Zig compiler does, without attribution. Not good, even if it is useful to popularize the trick.

Incidentally, I’ve been thinking about this recently, and it seems you can get even more compact:

You can encode extra information in the order of nodes. So you can reduce 2x u32 to just a single u32, storing subtree size. You’ll loose random access to nth child, but it’s unclear if that matters. If the child count is larger, you want to iterate them anyway, and if it is small constant, the access is O(1). I am very curious (as in, writing a parser and agonizing over which repr to pick) to learn what wins here. Is that extra u32 matters?

You can go further, and observe that for most nodes children count is known statically, and for dynamic nodes you can inject a synthetic “this was the last child”. You loose the ability to iterate just direct children, jumping over indirect descendants. But if you are doing white tree processing, maybe that’s fine? This I gather is what Carbon does.

Some recent discussion: https://zsf.zulipchat.com/#narrow/channel/454360-compiler/topic/Denser.20AST/near/609424340