Documentation channel: current development main at compiler checkpoint 1d7e15e. The latest tagged release is v0.0.3; pages identify APIs that are not yet released.

Performance methodology

Performance numbers in the Strut project are development baselines until a benchmark explicitly compares equivalent workloads on a controlled machine. The goal is to make regressions visible before making public claims.

What is measured

• cold and incremental compile time;
• stripped executable size;
• cold startup time and idle RSS;
• arithmetic, collections, JSON, pointer, lambda, threading, and async microbenchmarks;
• SQLite and HTTP application workloads;
• static versus dynamic linking where the comparison is meaningful.

Build modes

Debug and release results are kept separate. Release builds currently use optimisation, LTO where supported, dead-code elimination, and symbol stripping where appropriate.

Reproducibility

Raw benchmark output belongs with the benchmark scripts. Machine, compiler, target, build mode, dependency versions, and benchmark parameters should be recorded so later results can be compared honestly.

Interpretation

A microbenchmark is evidence about the operation it measures, not proof that Strut is globally faster than another language. Dogfood applications and end-to-end workloads are used alongside microbenchmarks before optimisation decisions are made.

Compiler profiling

The bootstrap compiler can expose its frontend/backend split directly. Use --timings to print phase timing and --emit-cpp to stop after generating the bootstrap C++.

strut app.p --release --timings -o app
strut app.p --release --emit-cpp generated.cpp

The benchmark workspace contains scripts for cold and incremental builds, generated-C++ compile/link timing, Linux perf, disassembly and assembly comparison. Keep raw before/after results when making optimisation changes.

Standard-library profiling

The profiling workspace measures collection workloads, whole-file reads, filesystem traversal, per-module compile cost, emitted C++ size, project-scale incremental builds, and generated-code budgets. Equivalent workloads are compared against C++, Rust, and Go where the required toolchains and matching standard-library semantics are available.

Module profiling is especially important for Strut's explicit standard-library model: a program that enables one collection should not silently pull in unrelated JSON, HTTP, SQLite, or filesystem machinery.

Strut 0.0.3 certification

The 0.0.3 compiler uses focused generated runtimes for string-only, plain-thread, and compatible atomic programs. In a direct A/B repeat against the immutable v0.0.2 compiler, using identical current fixtures and release flags, Hello World improved from 1,659 ms to 315 ms (about 81%) and plain threads improved from 2,112 ms to 795 ms (about 62%).

The broader campaign on the documented Intel i7-12700H/GCC 15.2 certification host measured approximately 2,070 ms to 306 ms for Hello World (about 85%) and 2,618 ms to 729 ms for plain threads (about 72%). Normal host-load variation explains the difference between runs. These measurements describe that controlled environment, not universal latency guarantees.

The complete methodology, raw samples, generated-code sizes, cross-language results, and targeted package/LSP/filesystem/HTTP profiles are retained in the benchmark repository certification report.