Benchmarks

When we say Sampularity stays fast on a huge library, this is what we measured, on what machine, and where it does not hold. Every figure comes from a named test in the source tree.

The short version

Scrolling the table costs the same six milliseconds whether the library holds a hundred thousand samples or five million. That is not a trick of tuning: the table is virtualized, so fetching a screenful depends on the size of the screen, not the size of the library. It is the one figure on this page we would call the point of the whole thing.

What we measured it on

Three catalogues. The first is a real, grown sample library: 122,792 samples from purchased packs, with real tags, real tempo values, real folder structure. The other two are that same catalogue multiplied 8× and 41×, so that row counts, row widths and, importantly, the distributions that make database work slow are preserved.

We are telling you they are clones because it matters: multiplying a catalogue does not touch the filesystem, so the two big catalogues cannot say anything about import speed. The import figure further down is therefore measured on 35,451 real audio files instead.

One library holding five million samples

The table above uses the biggest library that happens to exist inside each catalogue. Since our stat line talks about samples per library, we also measured the case it actually describes: a single library containing all 5,034,472 samples.

Scrolling stays in the milliseconds even two and a half million rows deep. Sorting a library that size does not, see the limits below.

Importing a sample pack

This one is measured on real files: a 35,573-file, 46.8 GB commercial loop bundle, copied to a local NVMe drive so the figure reflects the software rather than a network share. Sampularity’s first import pass reads directory metadata only, no decoding, which is why samples become browsable and playable long before the audio analysis has looked at them.

122 of the 35,573 files were skipped as non-audio. Audio analysis (tempo, key, timbre, tagging, embeddings) then runs on background threads while you browse.

Starting a preview

Landing on a sample decodes it and hands it to the player: that is where the sound starts. Measured on the same commercial bundle: 300 files taken every 118th so the selection spans the whole corpus rather than one folder of kick drums, each read cold from disk, plus the ten largest files in it. Three runs on different file selections, so the spread below is run-to-run variation and not a single lucky number.

These figures are the software only: your audio device adds its own buffer (~10 ms at a typical setting), and none of it depends on how large your library is. This measurement also changed the code: drawing the waveform used to happen between the decode and the sound, which cost 43 ms on that five-minute file for no reason. It now happens afterwards.

Where it does not hold

A benchmark page that only shows its best numbers is not worth reading. These are the limits we know about:

• Sorting a million-row library takes seconds, not milliseconds. Between 2.2 and 3.7 s at 1,453,491 rows, and 8-12 s for a single library of five million. Under half a second at a few hundred thousand. Scrolling is unaffected; this is the one-off cost of clicking a column header.
• Filters that match most of your library take seconds. Filtering five million samples by file type or bit depth is 6 s, but it returns 4-5 million rows, so the time is the answer. No index can help with that.
• Search terms shorter than three characters are not accelerated. The substring index works on three-character windows, so one- and two-letter searches fall back to a full scan.
• The tone-character sliders scan. 4-5 s at five million samples, because those values live inside a compact analysis blob that has to be unpacked per row.
• The first launch on an existing huge library does background work. Roughly five seconds at 122,792 samples; around two and a half minutes at five million, while it builds its search indexes. The table is usable throughout.
• These numbers come from a fast machine. AMD Ryzen 9 9950X3D (16 cores), 96 GB RAM, Samsung 990 PRO NVMe SSD, Windows 11, release build, Rust 1.96.0, measured 30 July 2026. Anything dominated by reading from disk (the wide filters, similar samples, AI search) will be slower on a SATA SSD and much slower on a spinning disk.
• Not measured: import over a network share, import at the million-sample sizes, how long the audio analysis itself takes, or anything on macOS.

Why you can check this

Every figure above comes from a benchmark that lives in the source tree and is run by name, not from a stopwatch and a good mood. Two of them verify themselves rather than just timing: the word search compares its results against the slow formulation it replaced and requires the two row sets to be identical, and the tag sort key was checked row-for-row against its predecessor across all 5,034,472 rows with zero differences. A faster search that quietly finds different samples is not a faster search.

Figures apply to Sampularity 0.1.0. We re-measure when the code that serves these paths changes; if you find a case that behaves differently on your library, we would like to hear about it at support@sampularity.com.