bench/OneMail.Benchmarks compares OneMail with MimeKit 4.18.2 (a released NuGet package, referenced only from bench/) on the same bytes, in memory, with BenchmarkDotNet 0.15.8. bench/run-mime-rows.sh OUTDIR builds, runs every row (3 launches, 3 warm-up and 10 measured iterations each), measures peak memory in separate processes and prints the table. Run it alone on the machine. The ratio is OneMail median time / MimeKit median time; below 1 is faster. The bar is a geometric mean ≤ 1.0 across rows and no row above 1.25.

Inputs

Picked deterministically from the corpora that tools/corpus/fetch.sh fetches (never committed):

What each side does

Things that make the rows differ in kind, not only speed:

• OneMail's parse reads headers and structure and leaves bodies in the input as ranges; MimeKit's default parse copies bodies into content streams. The parse and write rows therefore reward the lazy design; the bodies row is the like-for-like one.
• MimeKit re-serialises its model on write; OneMail copies untouched ranges, which is what keeps output byte-identical.
• The mbox row is parse per message over a split, not a mailbox reader. MimeKit's own mbox-mode parser is not used: it starts a message at every From line, including ones inside bodies, and throws on the fragments of this file.
• Peak memory is measured by running one row's work in a loop for four seconds in its own process. The working-set figure is dominated by the runtime's allocation budget on a machine with a large cache, so read the allocation columns for memory behaviour.

Results (first run, no tuning needed)

Medians in ns per operation (per message for mbox); B/op is bytes allocated per operation.

Geometric mean 0.091 (x64, AMD Ryzen 9 7950X3D, 32 logical cores) and 0.093 (arm64, Apple M2, 8 cores); worst row 0.584 and 0.351. The one row where OneMail allocates more is build: it base64-encodes the attachment when the content is set, where MimeKit encodes while writing.

Benchmarks: Outlook-format rows (PST/OST, MSG, TNEF)

bench/run-outlook-rows.sh OUTDIR runs these rows. They use the same harness as the MIME rows (BenchmarkDotNet 0.15.8, 3 launches, 3 warm-up and 10 measured iterations; the 10k and 50k stores use 3 launches of 1 warm-up and 3 iterations because one walk takes seconds), the same ratio (OneMail median / comparator median, below 1 is faster) and the same bar: geometric mean ≤ 1.0 per area, no row above 1.25. Arguments after OUTDIR replace the default BenchmarkDotNet filter and skip the extra steps.

Comparators

Each is the released NuGet package, referenced only from bench/ and used through its public API. Versions are pinned in Directory.Packages.props.

The comparator packages pull in a System.Security.Cryptography.Pkcs build that carries an advisory (NU1902/NU1903). The bench project is never shipped, so it suppresses those two audit warnings and nothing else.

Inputs

The generated stores come from the test-side PST writer (tests/OneMail.Tests/Pst), which now leaves a free slot for each AMap page a larger file needs (MS-PST 2.2.2.7.2) and sets MSGFLAG_HASATTACH. libpff 20180714 opens the stores (pffinfo, and pffexport -m items exports them), OneMail and XstReader read them to the same counts, and a unit test builds a 20 MB store in every layout and reads it back with no defects. libpff's recovery scan (pffexport -m all) fails on them, so the reference below uses -m items. The writer holds the file in one array, so the largest store it can make is about 1.5 GB; the 826 MB store is the largest measured.

What each side does

Every message: subject, sender name and address, submit time, every recipient (name and address), the body, and every attachment's bytes read to the end into a discarded buffer. A verify step runs both sides over every input first and prints what each saw (verify.tsv); messages, recipients, attachments and attachment bytes agree everywhere except as listed below.

Things that make the rows differ in kind or in work:

• ClearContents. XstReader documents ClearContents() as the way to release what a message cached. On the 50,000-message store it made the walk 14 times slower (139 s against 9.9 s) and its peak working set no lower (157 MiB against 150), so the timed rows leave it off: the comparator's fastest correct use. The memory section shows both.
• XstFile.Dispose. It starts a background release that reopens the file; in a loop over a short walk that thread threw after the file was closed and ended the process, on Linux and on macOS. The rows leave the file to the garbage collector instead.
• 4 KiB layout. XstReader.Api 1.0.6 throws XstException: Unexpected header in compressed data stream on every 4 KiB-page store this writer makes, so those rows have no comparator and no ratio (OneMail alone: 1,000 messages in 92 ms on x64 and 100 ms on arm64, 10,000 in 1.19 s and 1.35 s). No real 4 KiB store was available to tell a writer fault from a reader gap (libpff 20180714 opens the layout but cannot read tables stored in data trees, which these stores use).
• MSG corpus. MsgReader read 40 attachments (268,647 bytes) where OneMail read 41 (274,743 bytes) across the 53 files: one 6,096-byte attachment is not handed out by MsgReader. The ratio is on slightly unequal work, in the comparator's favour.
• Folders. The folder counts differ (OneMail also counts search folders, 49 against 41 in the OST); messages agree.
• PST bodies. XstReader hands out one body (Body.Text); OneMail's PST row reads the best one, so the work is matched. MSG reads all three on both sides because MsgReader computes all three on request.
• Memory. Peak working set is measured in a separate process that repeats one row's work for at least four seconds, with DOTNET_GCgen0MaxBudget set to 32 MiB so the first-generation budget of a large-cache machine does not hide the live set. A background thread samples the working set every 10 ms (the runtime's own peak counter reads 0 on macOS). Single-message rows (MSG, TNEF) sit on the runtime's baseline and say nothing; the PST rows and the curves are the memory evidence.

Results

Medians; B/msg is bytes allocated per message (for msg-corpus, per file). Ratios are OneMail / comparator.

Both machines pass every area and every row with room to spare, so no tuning was done. Two rows allocate more than the comparator: the smallest MSG (107 KB against 81 KB) and the smallest TNEF stream (110 KB against 62 KB). Both are fixed per-message costs that vanish into the time ratio (0.46 and 0.23).

Memory over the large stores

Peak working set, repeating the walk (KiB, OneMail / XstReader.Api, ClearContents off):

OneMail's working set does not move between 1,000 and 50,000 messages (a file 50 times larger, 826 MB, in about 100 MB or 66 MB, most of it the runtime and its allocation budget). XstReader.Api grows with the store. The curve samples agree (working set in MiB at 10 %, 25 %, 50 %, 75 % and 95 % of the 50,000-message walk): OneMail x64 88, 95, 98, 98, 99 and arm64 58, 63, 63, 64, 64; XstReader.Api x64 102, 118, 129, 142, 146 and arm64 70, 85, 95, 108, 114. With ClearContents after every message its working set is flat but noisy (x64 75, 86, 135, 129, 119) and the walk takes 139 s on x64 and 144 s on arm64. The generated stores top out at 826 MB, so the claim is for that size; a 50 GB store needs a streaming test writer.

Native reference

pffexport -q -m items -f text (libpff 20180714, x64, writes every item to disk, so it is not like-for-like), wall seconds, median of 3: gen-u1k 0.24 s (OneMail 0.072 s), gen-u10k 2.73 s (0.715 s), gen-u50k 20.09 s (4.12 s), peak RSS 207 MB for 50,000 messages. The real files take under 0.03 s. Reported, not gating.

Machines and runs

BenchmarkDotNet 0.15.8, MimeKit 4.18.2, MsgReader 6.2.0, XstReader.Api 1.0.6. The raw tables are report.tsv, peak.tsv, curve.tsv, verify.tsv and pffexport.tsv in each run's output directory. Two script faults found after the runs and fixed in the script: the TNEF peak row for tika-testwinmail was routed to the PST path and has no line (it is the same 66,276 bytes as poi-quick), and on macOS the theirs-clear tag in curve.tsv was not applied (the second theirs block per store is the ClearContents run).