One runtime.
Different kinds
of work.

Read the workload first

A language score hides the tradeoffs.

Absolute latency

Startup and sustained work tell different stories.

Nift’s tiny no-op median was 2.463 ms, while the large arithmetic-loop invocation was 72.592 ms. Read the latter alongside native/JIT peers below: low invocation cost does not establish sustained execution throughput.

A dash (—) means the implementation was outside scope and deliberately excluded; it is not a zero or a failed measurement. Selected classes are not an overall ranking.

sanity/noop

sanity/output

sanity/loops

sanity/function-calls

arrays-strings-hash/scan

arrays-strings-hash/frequency-count

arrays-strings-hash/sliding-window

arrays-strings-hash/sort-index

arrays-strings-hash/map-set

dynamic-programming/fibonacci

graphs-trees-search/bfs

structured-data/json-parse

structured-data/json-transform

structured-data/json-traverse

filesystem/traverse

Measurement & correctness

Every sample earns its place.

Ten measured samples plus two retained warmups per job; serial execution, rotated order, C-supervised fork/exec-to-exit latency and Linux waited-child high-water RSS. Every invocation must exit successfully and match its golden output. Alternate numeric formatting is accepted only when exact finite Decimal values agree; rounded output does not count.

Preparation is outside timing. Every sample creates a fresh runtime process with OS caches uncontrolled. We call this fresh-process-repeated, correcting the old suite’s misleading identical cold/warm labels. Historical runs are not merged.

Implementation choices

Observation before interpretation.

Native/JIT collection mechanisms can earn an advantage in sustained computation; invocation cost matters more for tiny automation. Nift’s integrated file/data functionality may be useful without winning every row. No benchmark here prices maintainability or feature convenience.

Bash is excluded from structured-data, Fibonacci and BFS where unnatural. Its recursive file test uses find/wc; other implementations use native APIs. BFS compares idiomatic queue/distance structures rather than identical internals. JSON parse/traverse include the same fixture read. Helpers remain inside timing.

Frequency-count v2 streams counters consistently; sort-index describes sorting and indexed reads. The misleading two-pointer endpoint test is omitted. Three redundant sanity microbenchmarks and duplicate shell startup are omitted. JSON-mutate duplicated record transformation without proving persistent array mutation. Partial JSON-query and unimplemented SQLite/mixed/breadth families are explicit coverage gaps. More end-to-end practical workflows would strengthen relevance.

Separate recovery diagnostic

Same-node checks for the surprising changes.

Separate same-node diagnostic: exact clean source builds c8d9c266 (previous release), 7f7e487 (original candidate) and c14d068 (final), using the same GCC 13.3 / native Make -O2 configuration, CPU 0, ten measured samples plus two warmups per case/version, six-permutation adjacent ordering and unchanged source/output oracles. All 72 observations passed independent audit; these are not pooled into official peer tables.

Small/large calls improved 36.56% / 57.69% from the original candidate, with disjoint ranges and every paired final observation faster. Final versus release differed by −0.032 ms / +5.019 ms (−0.67% / +2.59%), with overlapping ranges. This supports substantial recovery to near-release latency, not exact equality or a statistically established residual regression.

Findings and qualifications · All raw samples and build identities · Independent audit.

Practitioner judgement / AI-DX

Choose for the actual workflow.

For a standalone general-purpose script, especially sustained data/compute work, I would usually choose Python (or a workload-appropriate native/JIT runtime), using the peer rows rather than Nift’s startup cost alone. Inside a Nift-owned project combining templates, files, build policy and tasks, I would choose Nift where the shared runtime and explicit contracts simplify agent maintenance. Human-plus-agent and agent-primary choices depend on those project requirements; the benchmark does not measure authoring error rates or prove that one language is universally best.

Machine-readable inputs, ownership and dependencies can be useful explicitness rather than redundant ceremony. These qualitative judgements do not turn the harness’s golden-output/fixture checks into automatic product guarantees. Memory remains a separately qualified waited-child high-water measure, not aggregate process-tree usage or a combined performance score.

Frozen environment

Exact source, tools and boundaries.

Final candidate Nift 4.12.0, exact clean source c14d06835bca515a5281e41da0e40219c2d60ef0; CLI SHA-256 7dd42dcee5ca4a6965f0823c0ae59198282da1eb77e0fcd4cae93a537870a6fb. Native Make -O2, GCC 13.3; dedicated g6-standard-4 (8 GB / four vCPUs), Ubuntu 24.04, timed processes pinned to CPU 0. OS caches are uncontrolled; this is not machine-cold timing. Historical hosts and diagnostic cohorts are never pooled.

Exact build identity · Frozen suite and tool pins · Actual compiler/package inventory.

Independent complete-count/distribution audit · Normalized measurements · Complete raw data and retained warmups. No failed or superseded attempt is substituted for this accepted series.

Reproduce / scrutinise

All observations are retained.

Complete accepted series; the frozen suite revision and exact invocation are recorded in its readiness and official controller files. Summaries are independently recomputed from raw observations.

Conclusion

Workload-specific evidence.

These results support bounded implementation comparisons, not one scripting-language league table. Algorithms are diagnostics; file/data rows start a practical corpus which should expand before making broad claims.

Nift Benchmarks

Three perspectives on one runtime.