Performance should be explained, not advertised.

Headline Results

Representative Operations

These rows are deliberately representative rather than exhaustive. The intent is to show the shape of the current results while keeping the page honest about what microbenchmarks can and cannot prove.

ns = nanosecond, μs = microsecond (1,000 ns = 1 μs). Lower is faster. "vs date-fns" >1 means mmntjs is faster.

Why mmntjs loses some date-fns rows

The losses are structural, not implementation gaps. Every moment() call constructs a wrapper object around a Date. That is the cost of preserving moment-compatible mutability, method chaining, and .fn/.prototype extensibility. date-fns operates on bare Date instances directly and avoids this overhead entirely.

Benchmark rows labeled [fresh] create a new instance per iteration. This amplifies the wrapper cost because mmntjs builds and destroys a wrapper object on every operation, while date-fns only allocates a plain Date. Real applications often reuse Moment objects across multiple operations, which amortizes the construction cost.

The standalone mmntjs/fns entry removes the wrapper layer entirely. It operates on plain Date objects and flips most of these losses to wins.

Temporal Comparison

Measured on Node.js 26 with native Temporal. Results shown as warm-path medians.

"Ratio" >1 means mmntjs is faster. <1 means Temporal is faster. Data from bench/temporal.ts on Node.js 26. Mutating operations use fresh objects per iteration (same methodology as the date-fns table above).

Temporal prioritizes immutable correctness over speed. mmntjs wins on mutation-heavy and diff-heavy paths where cached fields and mutability avoid repeated allocation.

Standalone Helpers

mmntjs/fns is the closer apples-to-apples comparison with date-fns.

Removing the Moment wrapper makes the comparison essentially lossless for mmntjs: mmntjs/fns wins or ties every row against date-fns, with a geometric mean of 1.78x. The few rows near 1.0x are bare Date.set* wrappers where both implementations make the same native call.

"vs date-fns" >1 means fns is faster. Rows at 1.0x are within measurement noise.

The bundle story is also different: a single format import measures about 507 B gzip, and a small parseISO + format + addDays bundle measures about 1.3 KB gzip.

Cross-Runtime Note

The performance docs explicitly validate key rows on Node.js 26 as well as Bun. That is important because absolute numbers move with the engine, but the useful migration claim is whether the relative advantage stays intact across runtimes teams actually deploy.

Why It Is Fast

The implementation specializes the common compatibility paths.

The speedups are not from one trick. They mostly come from doing less work on hot paths while preserving moment.js semantics: fewer allocations, less repeated Date work, less regex work, and narrower paths for common parsing, formatting, and arithmetic cases.

Workloads

How To Interpret Results

• Microbenchmark results vary by workload and runtime.
• Some comparisons are implementation-cost comparisons rather than perfect semantic equivalents, especially around date-fns calendar-difference helpers.
• Cold-start and warm-path behavior should be read separately when startup latency matters.
• Compatibility remains the higher priority when a faster path would change legacy behavior.
• Parse and eval cost are not captured by these microbenchmarks. They are tracked separately in the size and startup-cost measurements.
• For SSR, edge, or serverless environments, startup cost and dependency footprint should be evaluated alongside hot-path throughput.

Scenario-based reading

The metric that matters depends on your deployment environment:

These microbenchmarks measure hot-path throughput, which is one dimension of performance. Compressed transfer, parse time, and cold-start behavior are reported separately.

Reproducibility

A performance page for this project should make it easy for a skeptical engineer to rerun the numbers rather than trust a screenshot. The benchmark files live in the repository and are intended to be rerun locally with documented commands.

• bench/moment-compat.ts: moment.js vs mmntjs public table and appendix
• bench/date-fns.ts: object-API comparison against date-fns
• bench/fns.ts: standalone mmntjs/fns vs date-fns helpers
• bench/bench-regression.ts: Regression guard thresholds
• bench/bench-mem.ts: Memory footprint checks
• bench/temporal.ts: Native Temporal comparison

• bun run bench
• bun run bench:date-fns
• bun bench/fns.ts
• bun run bench:guard
• bun run bench:mem
• bun run bench:temporal

The benchmark source of truth is split between README.md and docs/perf/BENCHMARKS.md. This page should track those numbers rather than invent a separate performance story.

Package Size

Size is measured at multiple layers, not a single gzip number.

Runtime speed and package size answer different questions. The package-size page reports raw, minified, gzip, brotli, and bundled output sizes, along with scenario-based guidance for which metric matters in each deployment context. Compressed transfer size (gzip/brotli) is treated as one layer of the measurement, not the headline.

Key points for mmntjs specifically: core does not silently bundle timezone data, locale and timezone data are measured and reported separately, and the lite/full/temporal/timezone entry points have distinct size profiles. Tree-shaking and side-effect behavior are preserved so bundlers can remove unused paths.