Choosing between dart:developer logging and ServiceExtension for runtime‑controlled alerts with minimal production noise

Answer at a glance

• True zero‑overhead when alerts are disabled can only be achieved by removing the call entirely (compile‑time guard) or by guarding it with a flag that is false by default. • A ServiceExtension adds no per‑call cost when the extension is not invoked, but it is only useful when an Observatory session is attached; in a plain release binary it is inert. • The practical mix is to register a ServiceExtension that flips a global boolean, and let your log statements check that boolean before invoking log(). This keeps per‑call cost negligible when the flag is off and gives you on‑demand activation when you want to debug.

Why dart:developer log isn’t zero‑cost

Each call to log() incurs a small amount of work: the function creates a StackTrace, formats the message, and checks Logger.level. Even if the message is filtered out, the call still executes these steps, which can add up at high frequencies. The cost cannot be eliminated without a compile‑time guard that removes the call from the bytecode.

When ServiceExtensions really help

ServiceExtensions are only evaluated when the Dart VM’s Observatory is connected—either via the command line, an IDE, or a remote debugging session. If you run a release binary with Observatory disabled, the extension is never called, so it can’t trigger any actions. In that scenario the extension is effectively a no‑op, but the registration itself has a very small startup cost.

Observatory‑enabled production

• Start the VM with --enable-vm-service (or the default in dev builds).
• Register a ServiceExtension that toggles a global flag.
• When the flag is on, your code can call log() or perform any expensive diagnostics.
• When the flag is off, the extension is never invoked, so there is no runtime cost.

Hybrid approach for release binaries

In a release build where Observatory is not enabled, you can still get near‑zero overhead by combining a runtime flag with a compile‑time guard:

import 'dart:developer' as dev;

// Compile‑time guard – removed in release if kReleaseMode is true
bool _debugEnabled = !kReleaseMode;

// Runtime flag that can be toggled via a ServiceExtension
bool _serviceToggle = false;

void _maybeLog(String msg) {
  if (_debugEnabled && _serviceToggle) {
    dev.log(msg, level: 0);
  }
}

void main() {
  // Register the extension only if Observatory is available
  try {
    dev.ServiceExtensionHandler.registerExtension('ext/debug', (params) async {
      _serviceToggle = params['enabled'] == 'true';
      return {'status': 'ok'};
    });
  } catch (_) {}

  // Example high‑frequency call site
  for (var i = 0; i < 1_000_000; i++) {
    _maybeLog('Iteration $i');
  }
}

When _serviceToggle is false, the body of _maybeLog is never executed, so the only cost is the boolean check, which is negligible. In a release build _debugEnabled is false, so the if condition short‑circuits and the call is effectively removed.

Key take‑aways

• Zero overhead when alerts are disabled is only possible with a compile‑time removal of the call.
• ServiceExtensions are cost‑free when not invoked but require an Observatory connection to be useful.
• A hybrid guard + ServiceExtension gives you low per‑call cost and on‑demand activation without needing Observatory in production.

Missing detail that could change the recommendation

Does your production environment run with Observatory enabled (e.g., --enable-vm-service)? If so, a pure ServiceExtension approach may be sufficient; if not, the hybrid guard pattern is recommended.