logging.Formatter vs f-string: Localhost Lab

Intro — what this post promises

Format log lines with logging.Formatter vs f-string / %-format assembly — format-only, no handler I/O. This lab reports msgs/s on Linux localhost.

Related links:

• xml etree vs json localhost lab
• math fsum vs sum localhost lab
• fractions vs float localhost lab
• chainmap vs dict merge localhost lab
• ipaddress vs string prefix localhost lab
• statistics quantiles vs manual localhost lab
• random choices vs sample localhost lab
• itertools batched vs chunk localhost lab

Lab honesty (1 Oct 2026 IST): Python 3.13.5. Affiliates: 0. Differentiates from logging-vs-print (lab 51) — that post compared I/O; this one isolates Formatter.format vs manual string build on prebuilt LogRecords.

Verdict up front (n=50000): Formatter+asctime ~403971 msgs/s; f-string+strftime ~823931; Formatter plain ~1149467; f-string no asctime ~1599896.

Arms

Seven rounds, p50. Records carry extra host / lat attributes like structured logging extras.

Lab topology

n=50000 LogRecords · 7 rounds · p50
metric: msgs/s = n / p50_s
no StreamHandler / no disk write

Script: lab-evidence/125-logging-formatter-vs-fstring/results/run_lab.py.

Lead table (p50 msgs/s)

With a clock in the line, manual f-string (~823931) beat full Formatter (~403971). Drop asctime and f-string climbs further (~1599896).

Sample output

Formatter prefix (truncated): '2026-10-01 01:01:09,073 INFO [svc.api] request done id=0 host=n0 lat=0.000'. Manual peer without clock: 'INFO [svc.api] request done id=0 host=n0 lat=0.000'.

Why keep Formatter anyway

Handlers, filters, LogRecord factories, and library code expect Formatter. Hot paths that already hold fields can assemble an f-string for a metrics side channel — but do not fork two divergent layouts without a fixture. Lab 51 still owns the “print vs logging I/O” question.

Reading it for SRE work

• Standard app logging → Formatter (consistency > peak msgs/s).
• Ultra-hot debug string you control → f-string; measure with your fields.
• asctime dominates cost — omit it or use a cheaper clock policy if volume hurts.
• Never compare Formatter+handler I/O to bare f-string and call it a Formatter tax.

Keep one canonical layout in production so log shippers and alerts stay aligned.

asctime is the silent tax

The plain Formatter (no clock) reached ~1149467 msgs/s, while the asctime variant dropped to ~403971. Manual f-string without a stamp hit ~1599896. If your shipper already stamps at ingest, dropping %(asctime)s from the process Formatter is often the cheapest win — measure before and after on the same box.

This lab intentionally skips handler I/O so the Formatter vs f-string comparison is not drowned by write(2). Pair with lab 51 when you need print-vs-logging throughput under a real StreamHandler.

Pitfalls

• Benchmarking logger.info(...) (includes level checks + handlers) as if it were Formatter.format.
• Forgetting getMessage() lazy % args when comparing to f-strings that already interpolated.
• Divergent layouts between Formatter and manual strings breaking log parsers.
• Assuming %-format and f-string stay equal after adding timezone-aware stamps.

Reproduce

python3 lab-evidence/125-logging-formatter-vs-fstring/results/run_lab.py

Evidence: summary.json, summary.txt.

Limits

One Linux box. Format-only; no QueueHandler, no JSON formatter libs.

Takeaway

Format-only at 50000 msgs: full Formatter+asctime ~403971 msgs/s vs f-string+strftime ~823931. Prefer Formatter for real logging pipelines; use f-string when you deliberately own a hot, I/O-free format path.