Systems Performance Lab

Executive summary

Low-latency and high-performance systems are easy to mythologize and hard to measure. This lab is a structured place to practice C++ on Linux: write small programs, instrument them, and keep notes on what the numbers actually say.

TODO: Add public benchmark charts and repo links when you are ready to open-source the harness. Avoid fabricated speedups (e.g. “10× faster”) without methodology.

Problem

Ad-hoc “optimization” without a harness produces folklore. The lab exists to enforce:

A baseline before a change
Repeatable methodology
Explicit hardware/OS context
Separation of microbenchmarks from end-to-end latency

Context

Transitioning from data-platform engineering (JVM/Python/Spark ecosystems) toward systems programming and performance-oriented design. Tennis analogy: you do not improve serve speed only by watching highlights — you measure, drill, and adjust.

Role

Author of exercises, harnesses, and write-ups.

Constraints

Personal hardware (document CPU, memory, governor, compiler)
Time-boxed experiments over perfect frameworks
Prefer standard tooling (perf, compiler explorer notes, sanitizers) before custom profilers

Approach

Pick a narrow question (e.g., false sharing, allocation patterns, parsing strategies)
Implement A/B variants under the same build flags
Measure with a benchmark library + OS counters where useful
Write a short postmortem: hypothesis, result, surprise, next step

// Sketch: keep the hot path boring and measurable
// TODO: replace with a real public example from your repo
for (std::size_t i = 0; i < n; ++i) {
  sink += process(input[i]);
}

Architecture / technical decisions

Language: Modern C++ for control over layout and abstraction cost
Build: CMake + consistent -O / LTO experiments documented per run
Env: Ubuntu/Linux as the primary target

Difficult problems

Noise from frequency scaling, noisy neighbors, and timer granularity
Compiler elision defeating naive benchmarks (DoNotOptimize / ClobberMemory discipline)
Confusing throughput wins with tail latency wins

Tradeoffs

Focus	Gain	Risk
Microbenchmarks	Fast feedback	Irrelevant to production paths
End-to-end apps	Realistic	Slow iteration, more variables
Read-only study	Cheap	Weak muscle memory

Outcome

TODO: List concrete labs completed (e.g., “ring buffer study”, “JSON parse comparison”) once they exist publicly.

What I learned

Measurement is a skill; tools without process still lie
Data-platform instincts (lineage, reproducibility) transfer cleanly to perf work
Reading assembly occasionally is clarifying — not mystical

What I would change

Template a “lab report” format earlier
Automate environment capture (CPU info, governor, commit SHA) on every run
Pair each microbenchmark with one realistic workload