Performance

evlog adds ~7µs of overhead per request — that's 0.007ms, 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 5 out of 6 head-to-head comparisons. The only scenario where pino edges ahead is the wide event lifecycle — but the difference is within noise (1.03x), and evlog emits 1 correlated event where pino emits 4 separate log 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.

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 Nuxt setup loads logger + utils — about 5.1 kB gzip. 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

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

bun run bench                          # all benchmarks
bunx vitest bench bench/comparison/    # vs alternatives only
bun bench/scripts/size.ts              # bundle size