Runtime engineering
C1/C2, inlining, escape analysis, deoptimisation, safepoints and generated-code verification.
Principal JVM Performance Engineer
Building predictable systems beneath the framework layer.
I design and optimise latency-sensitive financial platforms, JVM runtimes and event-driven systems. My work spans architecture, JIT behaviour, memory allocation, concurrency, CPU caches and the operating system beneath the convenient abstractions.
10×+faster payment workload
75%lower memory footprint
90%lower infrastructure cost
10+ yrsfinancial and runtime systems
Engineering domains
Performance across the execution stack
The fastest code is rarely produced by staring harder at a service method. Architecture, ownership, allocation and hardware behaviour have an irritating habit of mattering.
Concurrency
VarHandles, acquire/release, SPSC/MPSC structures, lock contention and cache coherence.
Memory
Allocation elimination, FFM, MemorySegment, fixed layouts and deterministic lifetimes.
Systems
Linux perf, NUMA, CPU affinity, ARM/x86, UDP, QUIC, shared memory and Rust.
Why Performance Lab exists
Explaining how software actually executes
Modern software is often discussed in terms of frameworks, languages, and architectural patterns. Those are important, but they rarely explain why software becomes fast, slow, scalable, or unpredictable in production.
The behaviour of a running system emerges from the interaction between CPUs, memory hierarchies, operating systems, runtimes, compilers, networking, and application architecture. Understanding only one of these layers is rarely enough to solve real performance problems.
Performance Lab was created to bridge that gap. Its purpose is not to collect isolated micro-optimizations or benchmark screenshots. Instead, it aims to explain how modern software actually executes, using interactive laboratories, reproducible experiments, source code, and measurable evidence.
Every laboratory is built around the same principles:
Mechanism before optimization
Explain the underlying mechanism before presenting an optimization.
Conceptual vs. measured
Distinguish conceptual models from measured behaviour.
Reproducible, not impressive
Provide reproducible benchmarks rather than impressive numbers.
Trade-offs over rules
Discuss trade-offs instead of universal rules.
Experimentation over memorization
Encourage experimentation rather than memorization.
Whether the topic is CPU caches, memory ordering, lock-free algorithms, JVM internals, Rust ownership, or low-latency networking, the objective remains the same:
Build intuition first.
Optimize second.
Measure always.
Performance engineering is not about making code clever. It is about understanding how software behaves under real workloads, making informed engineering decisions, and building systems that remain predictable as they evolve.
Interactive learning
Performance Lab
Small visual models for concepts that are usually explained with three paragraphs, a dubious analogy and avoidable suffering.
Selected work
Engineering case studies
Sanitised examples built around problem, evidence, design and result. No confidential internals and no miraculous benchmark folklore.
30–50 seconds to ~4 seconds
Parallel execution, allocation control and a 75% reduction in memory use.
Replacing synchronized contention
Lock-free, near zero-allocation infrastructure for a high-volume platform.
Database-bound to CPU-bound
In-memory computation reduced latency and infrastructure expenditure.
Guided curriculum
Performance Academy
A structured route from measurement fundamentals to runtime architecture. Not a “become principal in fourteen days” funnel. The universe has enough of those.
About the author
About Krystian Zybała
Krystian Zybała
Performance Engineer
I'm a Performance Engineer focused on runtime systems, low-latency software, and distributed architectures — JVM internals, memory management, concurrency, and more recently, the same approach carried into Rust.
Performance Lab is my long-term research and education project: interactive laboratories, reproducible experiments, and the reasoning kept next to the code.
Read the full about page → for the project's philosophy, roadmap, and how it's built in public.