Reference on Jasper

CPU and Memory: Map, Numbers, Estimates

Thu, 08 Oct 2026 00:00:00 +0000

This page is a map to keep open, not a post. It has three parts, in the order “where → how big and how fast → how to combine”:

Memory hierarchy: the hardware map, which boxes a read or a write passes through, and which post covers each box.
Performance parameters: latency, bandwidth and capacity for each box, how many requests can be in flight (MLP), and how fast the CPU itself wants data (bandwidth demand). They are rough magnitudes for intuition, not any particular machine.
Estimation model: one formula that strings the numbers of Part 2 together, to tell whether code is slow because it moves too much or because each move is slow.

When a later post covers a new hardware layer, it goes here. One layer up, the threads a market data message passes through are mapped in Trading System Architecture.

Trading System Architecture: Map, Times, How to Split

Tue, 20 Oct 2026 00:00:00 +0000

This page is an architecture map to keep open, and a companion to the hardware map: that page follows one memory access through the hardware, this one follows one market data message through the threads. It has three parts, in the order “where → how fast → how to split”:

Architecture map: the boxes a message passes through on its way to a fill, and which post covers each box.
Times: roughly how long each stage takes, to tell which stage is worth optimising. They are orders of magnitude, not measurements of any one system.
How to split: how industrial systems split threads, where they put queues, and where they have to join.

When a later post covers a new component, it goes here.

perf

Mon, 01 Jan 0001 00:00:00 +0000

An entry in the Reference list, not a page: the card links to the post named in target and takes its title, summary and date from it, so the post stays the only copy.

Performance Bottlenecks: Signals, Causes, Fixes

Thu, 22 Oct 2026 00:00:00 +0000

Once perf has found the hot spot, the next step is recognizing which bottleneck it is and how to fix it. This page writes each common bottleneck as a card: the signal is what you see in perf or in the source, the cause is why it is slow, the fix is how to change it, verify is how to confirm the fix, and the mechanism links to the post on this site that explains it.

Virtual Functions: vptr, vtable and Dynamic Polymorphism

Mon, 02 Nov 2026 00:00:00 +0000

A virtual call = load the vptr at the start of the object → load one slot of the class’s vtable → jump to that address. The expensive part is usually not the jump but the lost inlining; when the type is known at compile time, static polymorphism avoids it. To reuse a class’s implementation, make it a member, don’t inherit from it.

const, constexpr, consteval, constinit: Which One Guarantees Compile Time

Mon, 02 Nov 2026 00:00:00 +0000

const is about whether a value can change, not when it is computed; for compile-time values use constexpr variables and consteval functions; for static variables with initialization-order problems use constinit.

shared_ptr and enable_shared_from_this

Mon, 02 Nov 2026 00:00:00 +0000

The count lives in the control block and make_shared allocates once; to keep yourself alive from a member function, shared_from_this() shares the outside control block, while a second control block destroys the object twice.