Offline benchmark, four systems, five runs

Computer science poster

A computer science poster for a systems benchmark needs three things on the board: how the test set was made, what hardware ran it, and the cost of the win beside the win. This A0 landscape example shows a learned index benchmark with its data flow reconciling from 48,000 raw queries to 8,960 evaluated, and the 38 percent insert penalty printed in results.

Create a poster with OneCraftA0 Landscape, printed at 1189 by 841 millimetres

The whole board

The poster at full size, exactly as it prints. Every number, citation and caption on it was written for this example, so the layout is being judged on real content.

A learned range index cuts p95 lookup latency by 37 percent against a B-tree at equal memory

W. Ibarra ¹, S. Chen ¹, Y. Adler ²

1 Systems Group, Talbot Institute of Technology · 2 Northline Search Ltd

Abstract

Learned indexes promise to replace comparisons with a model prediction, and most published wins are measured on synthetic keys that no production system stores. This benchmark uses 44,800 real, anonymised range queries from one week of a product search log to compare a learned range index against three baselines: a B-tree, an adaptive radix tree and a hashed index. On 8,960 held out test queries the learned index answered at a p95 of 259 microseconds against 412 for the B-tree, a 37 percent cut, while using slightly less memory, 1.8 against 1.9 GB. The cost is stated with the win: insert throughput was 38 percent lower than the B-tree, so the result recommends the learned index for read heavy tables and rules it out for write heavy ones. Hardware, split and run counts are printed so the numbers can be reproduced.

Why range lookups

Profiling the production search service put range lookups at almost two thirds of index time: prefix queries, date windows and price bands all walk a sorted structure, and the B-tree that serves them has been the default answer for forty years. A learned index replaces the tree walk with a model that predicts where a key lives, then corrects the small error, and on sorted data that trade is usually a win. Its known weakness is updates, because the model ages as the distribution drifts. Published comparisons mostly benchmark uniform random integers, which flatters the model and tells an engineer nothing about their workload. The question this board answers is narrower and more useful: on one week of real queries from this service, with baselines tuned the way the service actually tunes them, how much latency does the learned index buy and what does it cost? Every system ran on the same machine, single threaded, from the same warm cache, and the tail is reported rather than the mean because the tail is what pages an on call engineer.

METHODS

Data. 48,000 range queries from one week of production logs, de-duplicated and anonymised before use; 44,800 kept.

Split. 80 / 20 by query hash: 35,840 train, 8,960 test. The split is by hash so repeated queries cannot leak across it.

Hardware. One machine: 16 core CPU, 64 GB RAM, NVMe storage; single threaded runs, warm cache, nothing else scheduled.

Runs. 5 runs per system; p95 over all 8,960 test queries per run, median of the 5 runs reported.

Baselines. B-tree with 4 KB nodes, adaptive radix tree, and a hashed index with 4 way buckets, each tuned as in production.

DATA FLOW

Raw log queries

n = 48,000

Removed: 2,140 duplicates, 1,060 malformed

n = 3,200

Clean queries

n = 44,800

Train (80 percent)

n = 35,840

Test (20 percent)

n = 8,960

Evaluated

n = 8,960

p95 latency (microseconds)

Figure 1. p95 latency in microseconds, median of 5 runs: B-tree 412, ART 388, hashed 351, learned index 259, left to right.

Source: Trial dataset, 2026.

Results

The learned index answered at a p95 of 259 microseconds against 412 for the B-tree, a 37 percent cut (259 / 412 = 0.63), and against 351 for the hashed index, a 26 percent cut. The adaptive radix tree sat at 388. Memory ran 1.9, 2.4, 3.1 and 1.8 GB for B-tree, ART, hashed and learned respectively, so the latency win did not buy itself with memory: the learned index was both the fastest and the smallest resident structure. The cost arrived where the literature said it would. Insert throughput on a replayed write stream was 38 percent below the B-tree, because model error grows as inserts drift the key distribution and the correction step lengthens. Retraining restored lookup latency but is a stop the world cost this benchmark did not hide: it is why the conclusion recommends read heavy tables only. The tail behind the tail matters too. At p99 the learned index held its lead, 341 against 583 microseconds for the B-tree, and its worst observed query was 1.2 milliseconds against 2.9. The wins concentrate exactly where the B-tree pays for deep descents: long ranges over dense key regions, where the model lands within a node of the answer. On short point-like ranges the four systems were within 15 percent of each other, so a workload of point lookups would not justify the switch. All five runs per system agreed within 4 percent at p95, and the code, the query set and the run scripts are behind the QR code.

-37%

p95 latency against a B-tree

259 against 412 microseconds; 8,960 test queries, median of 5 runs

Discussion

Three boundaries around the claim. This is one dataset from one service: search ranges over a skewed key space, and a workload with a different shape earns a different board. It is single threaded: concurrent readers shift constants, though they shift them for every baseline at once. And it is read heavy by construction: the 38 percent insert penalty is printed in results, not a footnote, because it is the number that disqualifies the learned index for write heavy tables and any honest recommendation has to carry it. What survives those boundaries is still worth having: on the workload this service actually runs, the learned index is faster at the tail and smaller in memory than every baseline, and the split by query hash means none of that is memorisation of repeated queries. The deployment now planned puts the learned index on the read replica path only, with the B-tree retained on the write path. One methodological choice deserves defending. Reporting the median of five runs at p95, rather than the best run, cost the learned index eleven microseconds but makes the number one an engineer can expect to see again; benchmarks quoting best runs are how learned structures earned their credibility problem in the first place.

p95 259 against 412 microseconds for the B-tree

Memory 1.8 against 1.9 GB

Inserts 38 percent slower, so read heavy tables only

Code and query set by QR

REFERENCES

1.Ibarra W, Chen S. Range query workloads in production search: a measurement study. Systems Measurement Letters 2025;9(1):14-29.

2.Adler Y, Ibarra W. Tail latency reporting for index benchmarks. Benchmarking Practice 2024;6(2):88-101.

3.Chen S, Novak L. Learned structures under distribution drift: retraining costs. Data Systems Notes 2023;11(4):203-217.

Block by block

What each block on the board is for, in the order a reader walks it.

Title band and authors: The title states the result with its condition: a learned range index cuts p95 lookup latency by 37 percent against a B-tree at equal memory. The industry partner whose logs supplied the queries is the second affiliation, and the QR code links the code and query set.
Abstract and introduction: The abstract leads with what makes this benchmark different, real queries rather than synthetic keys, and prints the headline numbers with their cost. The introduction reports that range lookups are almost two thirds of index time in this service, which is the fact that justifies the whole study.
Methods: data, split, hardware, runs: Five protocol entries pin down reproducibility: the one week log and its cleaning, the 80 20 split by query hash so repeats cannot leak, the machine, 16 cores, 64 GB, NVMe, single threaded, the five runs with median of p95 reported, and the three baselines tuned as in production.
Data flow: The six node flow shows the test set being made: 48,000 raw queries, 3,200 removed in the aside as 2,140 duplicates and 1,060 malformed, 44,800 clean, splitting to 35,840 train and 8,960 test, all 8,960 evaluated. Reviewers ask how the split was made before they ask anything else.
p95 latency (Figure 1): Four bars, one per system, same unit: 412, 388, 351 and 259 microseconds. The chart holds one metric only; memory and insert throughput stay in the text. On a dark showcase layout a single bright chart reads from across a demo floor, which is what this layout is for.
Results and the key number: The results block prints the arithmetic, 259 over 412 is 0.63, the p99 follow up where the lead holds at 341 against 583, and the honest boundary: on short point like ranges the four systems sit within 15 percent of each other. The stat block carries -37 percent with its denominators.
Discussion: Three stated boundaries: one dataset, single threaded, read heavy by construction. The insert penalty gets the discussion sentence it deserves, since it disqualifies write heavy tables, and the deployment plan follows the evidence, learned index on the read replica path only.
Conclusion points and references: Four bullets: the p95 numbers, the memory comparison, the insert penalty with its consequence, and the code link. The three references are invented for this fictional study, because the reference block is required on this layout; on your board, replace them with your sources.
How to adapt this board: Put your own systems as the bars and keep one metric per chart, with the others as sentences. Use the flow for your dataset pipeline, itemising what was removed and why, and print the trade off beside the headline, because a benchmark poster that hides its cost gets exactly one question at the stand.

What makes this board work

The split is a diagram

The six node flow shows 48,000 raw queries becoming 35,840 train and 8,960 test, with the 3,200 removals itemised in the aside. How the test set was made is the first reviewer question, answered before it is asked.

The cost is printed

Insert throughput 38 percent below the B-tree sits in the results block and again in the conclusion points, which converts the poster from advocacy into engineering.

One metric per chart

The single figure carries p95 only, 412 down to 259 microseconds, while memory and p99 live in the text, so the chart makes one comparison cleanly instead of three badly.

Questions people ask

What goes on a computer science poster?

The problem, the dataset and how it was split, the hardware, the baselines, one chart of the headline metric, the trade off, and a link to code. This board spends a whole block on the data flow because in systems work the benchmark is only as credible as its test set.

Can the flow block show a data pipeline?

Yes. The flow is six labelled boxes with counts and one aside, and nothing about it is specific to clinical trials. This board uses it for raw queries through cleaning to a train test split, and the same shape fits a scraping pipeline, an ETL job or a labelling workflow.

Which chart kind for latency comparisons?

Vertical bars, one per system, one unit, ordered however your argument reads best. The figure slot offers ten chart kinds, and the discipline that matters is refusing to mix metrics on one chart; this board keeps memory and insert throughput as sentences beside the single p95 chart.

Should I show a table of all metrics?

This dark showcase layout has no table slot; the table led landscape board carries an eight row by four column table if you need one. For a benchmark with two secondary metrics, sentences in results work fine, and they force you to say which number actually matters.

Is a dark board right for a demo day?

Yes, that is what this layout exists for: a dark canvas with one bright chart carries across a demo floor better than a white board under bright screens. This example runs the indigo night theme; for a formal conference hall the same content works on any light theme without edits.

Where does the code link go?

The QR slot, and this board also spends its last conclusion point on it. For a systems audience, code and query set availability is part of the claim, so the link belongs on the board proper rather than only in the paper the QR resolves to.

Build your own in about a minute

The button below opens the generator with this use case already described. Change the wording to match your own, generate, then edit anything you like.

Make my computer science poster

Sources

Written and checked by the OneCraft team. Last checked 2 September 2026.