Benchmarks

The numbers on this page are reference figures from a controlled BenchmarkDotNet run. Real-world performance depends on record size, schema complexity, serialization choice, index configuration, storage media, and hardware — treat these as relative indicators.

Test environment

Record schema

All benchmarks use the same record type:

public class BenchmarkRecord
{
    public long Id { get; set; }
    public string Name { get; set; }        // ~16 chars
    public string Category { get; set; }    // ~8 chars
    public DateTime CreatedAt { get; set; }
    public DateTime UpdatedAt { get; set; }
    public decimal Amount { get; set; }
    public int Count { get; set; }
    public bool IsActive { get; set; }
}

The custom serializer writes a compact binary format using BinaryWriter (fixed-width fields; strings length-prefixed). The custom cloner copies all eight properties by value: the six value-type fields are bit-copied, and the two string fields are reference-copied — no new heap allocation occurs during cloning.

Workload

Scenarios

Four configurations are benchmarked to isolate the impact of each optimization. Each row’s name shows what it builds on — note that scenarios 3 and 4 both branch from scenario 2, not from each other.

All four scenarios use durable storage: every insert and update is flushed to disk. MemDb also supports ephemeral-only modes that skip persistence entirely; write throughput in those configurations will be higher.

Throughput

Single-threaded steady-state measurements.

Scenario 1 — Defaults

This is the zero-configuration baseline. JSON parse and serialize runs at every cache boundary — once on write, and again on every read through the round-trip cloner — and by-id operations also pay for a full sequential scan to locate the record.

Scenario 2 — Custom clone + serialize

Replacing the JSON serializer with a compact binary format and the JSON round-trip cloner with a property-copy implementation removes parse and serialize cost from every operation. Update, delete, and find by id are still scan-based — the gain comes from eliminating JSON overhead, not the lookup.

Scenario 3 — Custom clone + serialize + identity index

The identity index’s impact on update, delete, and find by id is the most pronounced result on this page. Each of those operations must locate the record before acting on it, and the identity index reduces that step from a full sequential scan to a direct pointer lookup.

Scenario 4 — Custom clone + serialize + applied index

The applied index does not accelerate update or delete by id — those remain scan-based — and adds maintenance overhead on every write, so insert, update, and delete throughput sits slightly below the no-index scenario.

Memory footprint

Per-record overhead in the managed cache, measured as the delta in GC.GetTotalMemory(true) before and after inserting N records into an open database.

Per-record cost stabilizes at ~193 bytes for the benchmark record schema. The total process working set at 1,000,000 records was 263 MB, decomposing into ~193 MB of cached records plus ~70 MB of fixed overhead (CLR, JIT, MemDb internals, native buffers).

On-disk format

Pointer map overhead is exact and independent of record content:

Data file size depends on the encoding and whether encryption is enabled:

Cold start

Time from MemDb.Open to first successful read, measured with System.Diagnostics.Stopwatch.

The custom binary serializer roughly halves cold start time compared to the default JSON deserializer. Adding AES-256 decryption brings cold start back in line with the JSON baseline — every record must be decrypted on load, which offsets the gains from the faster binary format.

Reproducing these numbers

The benchmark harness lives in the MemDb repository, under benchmark/HatTrick.MemDb.Benchmarks. It’s a BenchmarkDotNet console project that consumes the HatTrick.MemDb NuGet package — no local build of MemDb is required.

git clone https://github.com/HatTrickLabs/mem-db.git
cd mem-db/benchmark/HatTrick.MemDb.Benchmarks
dotnet run -c Release

The run executes, in order:

• Memory footprint — cache delta at increasing record counts
• Cold start — MemDb.Open to first read, across record counts and serializer/encryption combinations
• Throughput — the four scenarios above, via BenchmarkDotNet (DefaultsThroughput, CustomCloneAndSerializeThroughput, CustomCloneAndSerializeIdentityIndexThroughput, CustomCloneAndSerializeAppliedIndexThroughput)

BenchmarkDotNet writes per-scenario reports (Markdown, HTML, CSV) to BenchmarkDotNet.Artifacts/results/. A full run — including the 10,000,000-record cold start passes — takes a while; expect it to run for several minutes.