Performance

evlog adds ~3µs of overhead per request, that's 0.003ms, orders of magnitude below any HTTP framework or database call. Performance is tracked on every pull request via CodSpeed.

evlog vs alternatives

All benchmarks run with JSON output to no-op destinations. pino writes to /dev/null (sync), winston writes to a no-op stream, consola uses a no-op reporter, evlog uses silent mode.

Results

evlog wins 4 out of 7 head-to-head comparisons, and the wins that matter most are decisive: 7.7x faster than pino in the wide event pattern, 2.3x faster logger creation, and 3.3x faster deep nested logging. consola edges ahead on simple strings and burst (it uses a no-op reporter with no serialization), but evlog produces a single correlated event per request where traditional loggers emit N separate lines.

What is the "wide event lifecycle"?

This benchmark simulates a real API request:

const log = createLogger({ method: 'POST', path: '/api/checkout', requestId: 'req_abc' })
log.set({ user: { id: 'usr_123', plan: 'pro' } })
log.set({ cart: { items: 3, total: 9999 } })
log.set({ payment: { method: 'card', last4: '4242' } })
log.emit({ status: 200 })

const child = pinoLogger.child({ method: 'POST', path: '/api/checkout', requestId: 'req_abc' })
child.info({ user: { id: 'usr_123', plan: 'pro' } }, 'user context')
child.info({ cart: { items: 3, total: 9999 } }, 'cart context')
child.info({ payment: { method: 'card', last4: '4242' } }, 'payment context')
child.info({ status: 200 }, 'request complete')

Same CPU cost, but evlog gives you everything in one place.

Why is evlog faster?

The numbers above aren't magic, they come from deliberate architectural choices:

In-place mutations, not copies. log.set() writes directly into the context object via a recursive mergeInto function. Other loggers clone objects on every call (object spread, Object.assign). evlog never allocates intermediate objects during context accumulation.

No serialization until drain. Context stays as plain JavaScript objects throughout the request lifecycle. JSON.stringify runs exactly once, at emit time. Traditional loggers serialize on every .info() call, that's 4x serialization for 4 log lines.

Lazy allocation. Timestamps, sampling context, and override objects are only created when actually needed. If tail sampling is disabled (the common case), its context object is never allocated. The Date instance used for ISO timestamps is reused across calls.

One event, not N lines. For a typical request, pino emits 4+ JSON lines that all need serializing, transporting, and indexing. evlog emits one. That's 75% less work for your log drain, fewer bytes on the wire, and one row to query instead of four.

RegExp caching. Glob patterns (used in sampling and route matching) are compiled once and cached. Repeated evaluations hit the cache instead of recompiling.

When evlog might not win

The benchmarks above measure CPU + serialization cost on the main thread, with no real I/O. That's the standard setup pino, winston, and logtape use for their own benchmarks — but it leaves out a few scenarios where another logger can edge ahead. Be honest about these:

Fire-and-forget hot paths with pino-via-worker-thread. In production, pino is typically configured with a worker-thread transport (pino-pretty, pino-loki, vendor-specific transports). The serialization and I/O move off the main thread entirely. For a workload that emits hundreds of thousands of log.info('foo') lines per second with no context accumulation, pino-via-worker can hit ~2-3M ops/s on the main thread because it's just queueing. We can't benchmark that mode fairly inside a single-threaded vitest process, so it's not in our table — but it's a real scenario where pino is faster.

CLI / pretty-only output without serialization. consola's no-op reporter mode in our benchmarks (level: 4, reporters: [{ log: () => {} }]) skips JSON serialization entirely. That's realistic if you're using consola for a CLI with terminal-only output, but it's why consola wins "simple string" and "burst" — it's not doing the same work. evlog and pino both serialize to JSON; consola in those benchmarks does not. If your use case is "pretty terminal output, no shipping logs anywhere", consola is genuinely lighter.

Single log.info calls, no context accumulation. evlog and pino are roughly tied on pino.info('hello') vs evlog.info('hello') (1.83M vs 1.09M ops/s in our run, but the gap closes further if pino runs in async mode). evlog's ~7.7x advantage shows up specifically when you'd otherwise emit N separate lines for one logical operation. If you genuinely log one line per call and don't accumulate, the speed delta is much smaller — pick evlog for the API ergonomics (log.set + structured errors), not raw throughput.

Wall-clock variance is real. Vitest bench numbers shift ±5-10% between runs on the same machine (thermal throttling, GC, other processes). The numbers above come from a single run on a MacBook; CI tracks regressions via CodSpeed's CPU-instruction counting (deterministic, ±0.5% noise floor) but the absolute hz values in this page are the wall-clock snapshot, not a guaranteed floor.

The takeaway: the wins are real for the wide event pattern, but if your stack is "pure fire-and-forget pino with a worker transport", that's the one place we don't claim to beat.

Real-world overhead

For a typical API request:

For context, a database query takes 1-50ms, an HTTP call takes 10-500ms. evlog's overhead is invisible.

Bundle size

Every entry point is tree-shakeable. You only pay for what you import.

A typical Node.js bundle (initLogger + createLogger) measures ~6.3 kB gzip end-to-end after tree-shaking; adding createRequestLogger, createError, parseError, and useLogger brings the bundle to ~7.2 kB gzip. Adapters and framework integrations sit on top: Hono is 617 B, Express 734 B, Axiom 1.48 kB. Bundle size is tracked on every PR and compared against the main baseline.

Detailed benchmarks

Logger creation

Context accumulation (log.set())

Event emission (log.emit())

Payload scaling

Sampling

Enrichers

Error handling

Middleware pipeline

Methodology & trust

Can you trust these numbers?

Every benchmark in this page is open source and reproducible. The benchmark files live in packages/evlog/bench/. You can read the exact code, run it on your machine, and verify the results.

All libraries are tested under the same conditions:

• Same output mode: JSON to a no-op destination (no disk or network I/O measured)
• Same warmup: each benchmark runs for 500ms after JIT stabilization
• Same tooling: Vitest bench powered by tinybench
• Same machine: when comparing libraries, all benchmarks run in the same process on the same hardware

CI regression tracking

Performance regressions are tracked on every pull request via two systems:

• CodSpeed runs all benchmarks using CPU instruction counting (not wall-clock timing). This eliminates noise from shared CI runners and produces deterministic, reproducible results. Regressions are flagged directly on the PR.
• Bundle size comparison measures all entry points against the main baseline and posts a size delta report as a PR comment.

Run it yourself

cd packages/evlog

pnpm run bench                          # all benchmarks
pnpm exec vitest bench bench/comparison/ # vs alternatives only
pnpm exec tsx bench/scripts/size.ts     # bundle size