> Frankly, what we're trying to fix by the alias? It sounds like premature optimization. Reducing static code size / file size of the library by ~190 bytes or something like that IIRC for x86-64 for the current version, by avoiding a 3rd duplicate of the code (if the compiler inlines uuid_fmt()). Or reducing the cost of forcing it to inline for cases where the compiler chooses not to. On Wed, Apr 1, 2020 at 7:06 AM Karel Zak <kzak@xxxxxxxxxx> wrote: > BTW, would be better to make uuid_fmt() as inline function as we use > it in uuid_unparse_lower(), uuid_unparse_upper() and uuid_unparse()? > It's already static. The compiler is completely free to inline it into both (or all 3) callsites, depending on tuning heuristics. If we expect that only one of the 3 will normally be "hot" at the same time, then yeah forcing the issue with __attribute__((always_inline)) to make sure we don't get a jmp tailcall is nice. In practice for x86-64, gcc9 -O2 chooses not to inline because it's fairly large. So that would be good for programs that only ever call uuid_unparse(), not a mix of upper/lower. static inline would make zero difference, unless that keyword also affects GCC's / clang's inlining heuristics as well as telling it that a definition will be visible for any other compilation unit, so the compiler doesn't need to emit a stand-alone definition if it inlines it into all callers. (And nothing takes its address, etc.)
