Per message the source holds up to two internal functions with the message text — the language selection and every text element in them:

FunctionWrites toUsed by
InternalStreamerFunctionOf_<Name>( std::ostream &stream, params… )a streamstreamable PrintOn, error functions
InternalBuilderOf_<Name>( std::string &out, std::locale const &loc, params… )a stringstring, syslog, exception text

Each is generated only when an artefact needs it. Both are static (inline in an INLINE module).

The builder

static void InternalBuilderOf_NotFound( std::string &internal_out,
  [[maybe_unused]] std::locale const &loc,
  [[maybe_unused]] std::string const & path )
{
  internal_out.reserve( internal_out.size( ) + 29 );
  // language selection, then per text element:
  internal_out += "not found: ";
  mstring_local_v1::InternalAppend( internal_out, loc, ( path ) );
}
  • Literal text is appended directly; the reserve covers the longest language's literals plus 16 bytes per value.
  • InternalAppend appends a value exactly as stream << value on a stream imbued with loc would write it: a string-like value as it is, an integer with std::to_chars when loc is the C locale, anything else through a std::ostringstream.
  • A macro with formats always goes through a fresh std::ostringstream imbued with loc, with the formats applied — nothing leaks.

Per call, for a two-parameter message (gcc 11, -O2, the repository's bench/): 94 ns, against 418 ns through an ostringstream and 71 ns for hand-written appends.

The streamer

The same structure, writing stream << … statements. A macro with formats saves the stream's format with copyfmt, applies the formats, writes the value and restores it.

Language selection

A message with several texts first reads the locale name and tries the languages in order — see Texts & locale selection. That costs about 40 ns per call for five languages; a message with one text has no selection code at all.