It is a featureful formatting library, not simply a library for slow printing of ints and strings without any modifiers. You can't create a library which is full of features, fast, and small simultaneously.
The surest bet would be a compile time feature flag to disable floating point formatting support which it does have.
Still, that’s 8kib of string formatting library code without floating point and a bunch of other optimizations which is really heavy in a microcontroller context
Especially if you extended them to indicate assumptions about the values at compile time. E.g., possible ranges for integers, whether or not a floating point value can have certain special values, etc.
They probably should be passed at compile time, like how zig does it. It seems so weird to me that in C & C++ something as simple as format strings are handled dynamically.
Clang even parses format strings anyway, to look for mismatched arguments. It just - I suppose - doesn’t do anything with that.
It’s also important to note that the floating point code only contributed ~44kib out of 75kib but they stopped once the library got down to ~23kib and then removed the c++ runtime completely to shave off another ~10kib.
However, it’s also equally important to remember that these shavings are interesting and completely useless:
1. In a typical codebase this would contribute 0% of overall size and not be important at all
2. A codebase where this would be important and you care about it (ie embedded) is not served well by this library eating up at least 10kib even after significant optimization as that 10kib that is intractible is still too large for this space when you’re working with a max ~128-256kib binary size (or even less sometimes).
And run time format strings are a concise encoding for calling this functionality. I would assume that compile time alternatives take more space.