One where the dependency graph is sparse.

Sure, and this is the kind of thing you would be paying attention to if you were “optimizing for incremental builds”. Introducing a header with forward declarations for example.

Parallelization of modular builds makes the modular build win over the unity build after a certain size. But if you built sequentially it would be slower.

And it's my opinion that we should optimize for incremental builds instead of global time.

What stage you are asking? This is my actual experience on different projects. But it also seems self-evident that separate compilation helps with incremental builds while building everything as a single compilation unit is better is faster than building small modules and then linking.

Often the same people that say this go write Rust and write loops creating and destroying tons of Strings that cost much more than allocate than they would in a language with a good GC.

This is a common thing and the reason behind avoiding pointers to register-sized values across function boundaries. An add10() that returns the value added by 10 is better than the one that mutates through the pointer. Totally fine if inlined though.

If we forbid the inlining, the caller is forced to put i on the stack

str r0, [sp, #4]

to pass the ptr to add10

add r0, sp, #4 // put the ptr relative to the stack ptr on r0 before call

then the value is loaded from the stack into r1 before the printf call

ldr r1, [sp, #4]

It’s only a 20-ish% increase from June in Brazil, so I’m securing mine before they have to renew their inventory and increase it even more.

Oh, second ed is out already?

De longe

It's annoying in C++ to query an std::unordered_map<std::string, T> when what you have is a std::string_view (pointer, "borrowed") instead of the std::string (allocated on the heap, "owned").

Add to Playlist gets worse every month or so

Wondering if this is the kind of thing that @welltypedwit.ch will say is not good in practice.

There is a nice online demo/playground: se-tuebingen.github.io/oopsla-2025-...