Mechanism before optimization
Explain the underlying mechanism before presenting an optimization. A trick without a model just becomes cargo-culted advice.
Read me first
This page documents a project, not a career.
Performance Lab is a working engineer's research notebook: why it exists, the principles every laboratory follows, what's actually built, what's next, who maintains it, and the spec-driven workflow used to build it — all in one place, the way a serious project's own documentation would explain itself.
3interactive laboratories
0runtime npm dependencies
60+automated reducer tests
100%spec-driven via OpenSpec
Why it exists
Frameworks explain what to call things. They rarely explain why systems behave the way they do.
Most performance problems are not solved by reading the framework's documentation more carefully. They're solved by understanding what's underneath it: how the CPU actually fetches and caches memory, how the JIT compiler decides what to inline, how a coherence protocol moves a cache line between cores, how a runtime schedules threads onto hardware that does not care about your abstractions.
Individually, each of those topics has excellent specialist material — a hardware manual here, a JEP there, a conference talk somewhere else. What's harder to find is the connective tissue: a place that walks from "here's the mechanism" to "here's why it matters" to "here's how to go verify it yourself," for one topic at a time, without asking you to already be an expert in three adjacent fields first.
Performance Lab exists to be that place. Not a benchmark leaderboard, not a collection of "10x your Java app" claims, and not a course you pay for and forget. Every laboratory is a small, interactive, source-available explanation of one mechanism — built to be read, clicked through, questioned, and rebuilt on your own machine.
Engineering philosophy
Five rules every laboratory follows
These aren't aspirational. They're enforced — the OpenSpec workflow below turns each one into a requirement a change has to satisfy before it ships.
Conceptual vs. measured
Distinguish conceptual models from measured behaviour, explicitly and visibly. A simplified diagram is labelled as one — it is never confused with a benchmark.
Reproducible, not impressive
Provide reproducible benchmarks rather than impressive numbers. Every measured result discloses hardware, method, and raw data so you can question it.
Trade-offs over rules
Discuss trade-offs instead of universal rules. "Always pad your fields" and "always avoid locks" are both wrong somewhere — the lab says where.
Experimentation over memorization
Encourage experimentation rather than memorization. Every interactive model exists so you can change the input and watch what actually happens.
What you'll find here
Seven ways into the same underlying material
Same engineering, different formats — pick whichever fits how you learn.
LAB
Performance Lab
3 interactive laboratories with deterministic, keyboard-accessible visual models and Java/Rust code.
CASECase studies
Sanitised, real-shaped engagements: problem, evidence, design, and result — no confidential internals.
ARTArticles
Longer-form technical writing on JVM internals, concurrency, and hot-path design.
ACADAcademy
A five-level curriculum from measurement fundamentals to production performance leadership.
RESResearch
Deeper investigations into runtime and hardware behaviour that don't fit a single lab.
TALKTalks
Conference and meetup talks on VarHandles, Loom, garbage collection, and distributed pitfalls.
CONSConsulting
Engagements on JVM performance, low-latency architecture, and production investigations.
Current focus
What's shipped, what's next
Performance Lab's own roadmap — not a projection, the actual sequence of OpenSpec changes in progress.
Shipped
Cache Coherence and MESI
Coherence vs. consistency, the four-state MESI model, read-for-ownership, cache-to-cache transfer, and perf c2c methodology.
In progress
Memory Ordering in Java and Rust
Program order versus observed order, compiler and CPU reordering, happens-before, and data races — compared across VarHandles and Rust atomics.
Planned
CAS Contention and Backoff
Compare-and-set semantics, failed retries, contention collapse, exponential backoff, and why lock-free doesn't automatically mean low-latency.
Planned
SPSC Ring Buffer, rebuilt
Replacing the early prototype with a complete reference laboratory: bounded capacity, head/tail ownership, wrap-around, full/empty detection.
Planned
Thread-per-Core Architecture
Shared-nothing ownership, partitioning, affinity, handoff, backpressure, and predictable tail latency.
About the author
Who's writing this
Krystian Zybała
Principal JVM Performance Engineer
I'm a Performance Engineer working on runtime systems, low-latency software, and financial platforms — the kind of work where "it's probably fine" isn't an acceptable answer, and where the difference between a good and bad decision shows up as a number in a percentile chart.
Most of my career has been investigating why software is slow, unpredictable, or both, across JVM internals, memory management, concurrency, CPU efficiency, and production observability. More recently, I've been carrying the same approach into Rust — deterministic runtimes, lock-free data structures, and explicit memory management, without a garbage collector to blame things on.
Performance Lab is where that investigation gets written down properly instead of living in conference slides and internal wikis. It's a long-term project, built the same way I'd want a piece of production infrastructure built: incrementally, with a spec, and with the reasoning kept next to the code.
Built in public
Every change follows the same OpenSpec workflow
Nothing here ships because it "felt done." Each change moves through the same artifacts, in the same order, and the same automated gates run before it merges.
This site's source, including every lab you can click through, is a public git repository. New work starts as an OpenSpec change: a proposal stating the motivation and scope, a design defining the interactive model's state and events, a spec of testable requirements written as concrete scenarios, and a task list breaking the work into checkable steps.
Only after that does implementation start — and even then, nothing merges on trust. Every push runs the same gate a human reviewer would: lab metadata validation, asset-size budgets, HTML and link validation, accessibility smoke checks, a no-JavaScript fallback check, and a suite of pure, dependency-free unit tests for every interactive model's state machine.
Once a change ships, its spec deltas are synced into the site's living specification and the change is archived — so the documentation and the deployed behaviour never quietly drift apart.
Connect
Where to find me
INLinkedIn
Email
Professional background, and where I post when something new ships.
GHGitHub
Source code for this entire site, including every lab's implementation.
WEBWebosystem
Where consulting and engagement work is organised.
@contact@kzybala.pl — for consulting enquiries, corrections, or questions about a lab.