Post #4039767

2026-07-23 12:05 UTC

The simplest version of this problem is the kind you can solve with tree shaking. If a library has a bunch of functionality that you don't use (because another library consumer *does* or *might* use it), the final build may be able to omit a lot of that code, by a mechanism that isn't too far off from a mark-n-sweep garbage collector, treating your application's main function as the GC root. Some amount of this low-hanging fruit usually exists, but not necessarily enough to fill your stomach with a free lunch. Are you actually writing a library that depends on a library? Now you have multiple entrypoints (public functions) that someone might use, which means more GC roots of things someone *might*, use pinning dependency content in place. You also usually end up needing to track more state that someone might use. Okay, now all your structs take longer to malloc and copy and you need to gather more information to populate them, etc. Because "might" and "maybe" are expansive words in a cautious context.

Replies (1)

@MaddieM4@raphus.social 2026-07-23 12:12

Basically, it's only at the very final linking phase where we actually have maximum context for what functionality is actually required, what shapes of data are needed, etc. Really, it's at *invocation* time, but executables are usually a pretty nice boundary line for "here's a suite of things that are possible if you ask for them, as a complete and cohesive product." The goal is itself multifaceted here. The further back we get from final linking, the less specificity we have about what's needed vs could be needed. This is part of the ratchet pattern that bloats software over time. I'm not anti-library. This is what makes being a library author such hard work, if you actually care about the quality of what you make! A lot of the things I associate with software best practices (on my own terms of "best") basically require a specificity that is structurally denied to library authors. So... what do?

Open ##4039766