Skip to content

[FEATURE]: Convert f-string log calls to lazy % formatting for performance #76

Description

@rederik76

Is there an existing issue for this?

  • I have searched the existing issues

Problem statement

Approximately 130 log calls across 18 source files use f-string message formatting:

logger.debug(f"Loading files from {path}")
logger.info(f"Pipeline Details: {json.dumps(details.__dict__, indent=4)}")

F-strings are evaluated eagerly. The string is fully constructed before the log method is called, regardless of whether the message will actually be emitted at the current log level. For DEBUG calls in particular (which are suppressed in production), this means:

  • String interpolation, json.dumps, and other formatting work happens on every pipeline run even when logLevel = "INFO".
  • This is worse with the structured custom logger path since custom loggers that do not use the standard logging.Logger machinery do not benefit from the built-in lazy evaluation optimisation either (the cost is paid before the framework even calls the logger).

This is inconsistent with the Python logging best practice and with the custom logger contract documented in docs/source/feature_logging.rst (requirement 4: check level before formatting).

Proposed Solution

Convert all f-string log calls to %s positional argument style:

logger.debug("Loading files from %s", path)
logger.info("Pipeline Details: %s", json.dumps(details.__dict__, indent=4))

This is a purely mechanical change with no logic modifications. The %s style is lazy by default in Python's standard logging.Logger; the string is only formatted if the message will actually be emitted. Custom loggers implementing the contract in feature_logging.rst apply the same level check before formatting.

Additional Context

  • Planned branch: fix/log-fstring-to-percent (v0.14.1 patch on the logging PR, or bundled into a later minor).
  • No behaviour change, output is identical; only the point in time at which the string is constructed differs.
  • A small number of calls intentionally use eager formatting (e.g. where the value is already a string constant); these are noted and can be left as-is or converted for consistency.
  • This change also makes the codebase consistent with the custom logger contract.

Metadata

Metadata

Assignees

Labels

enhancementNew feature or request

Type

No type

Fields

No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions