Built in Rust. Verified by measurement.

Snipset's speed is not a slogan. Every headline number on this page is produced by a reproducible harness against the current release, then republished automatically with each new version. Nothing here is estimated from a blog post.

v0.6.780·Measured 2026-09-06

EXECUTIVE SUMMARY

Why this product wins on speed and why it will stay ahead

Three structural advantages that competitors cannot retrofit onto an Electron or webview architecture.

12.4MB

Real Windows installer, measured live

The current x64 MSI is 12.4 MB (setup EXE 9.6 MB), measured from the public update channel on 2026-09-06. Electron-based rivals commonly ship 80–250 MB installers because they bundle a full Chromium runtime.

Sampled on the release runner

Tray-idle memory footprint

Working-set RSS is sampled on a dedicated release machine after warm-up and published on every release. Typical webview/text-expander rivals idle between 150–450 MB (vendor-reported); Snipset's tray process carries no webview, no GPU process, and no cloud sync daemon.

Engine p50 published per release

Sub-millisecond typing hot path

The matching work between your keystroke and an expansion runs in pure native Rust against an in-process SQLite database: no webview, no IPC, no JavaScript in the hot path. The measured engine percentiles are shown in the harness section below.

HEADLINE METRICS

Four numbers, re-measured every release

Values marked 'measured' come from this release's data file. Anything not yet re-run on the release machine is clearly flagged instead of invented.

Installer Size

12.4MB

Windows x64 MSI, v0.6.780, measured from the live update channel.

Snipset MSI measured12.4 MB

Electron installer vendor-reported80–250 MB

Idle Memory

—

Working-set RSS at tray idle on the release machine, sampled after warm-up.

Snipset (Rust)pending release run—

Webview expanders vendor-reported150–450 MB

Cold Start

—

Process launch to tray-and-hooks ready on the release machine (measured from OS start).

Snipset pending release run—

Chromium runtime vendor-reported≈1,200–2,400 ms

Engine Match

—

In-process snippet match (p50) on a warm cache. No webview, no IPC, no JS in the hot path.

Engine match measured in-processpending

JS/browser-based expandersms scale, JS bridge

NATIVE RUST ARCHITECTURE

Why the numbers hold up at scale

Structural design decisions that keep Snipset fast today and prevent the performance cliff webview expanders hit as features grow.

Zero-IPC Hot Path

Keystrokes are captured by native OS hooks and matched directly against an in-process cache. There is no webview, no JavaScript thread, and no IPC round-trip between your keystroke and the expansion engine, the usual source of perceived lag in Electron and browser-extension expanders.

Embedded SQLite, WAL mode, in-process

Snippets and clipboard history live in an embedded SQLite database opened by the Rust process itself. Reads happen in the same process as matching, with WAL mode keeping disk I/O effectively out of the critical path: no remote sync server in between.

Native OS hooks (Win32 / Unix)

Global input is observed at the OS level through a lock-free queue rather than a polling loop. Expansions trigger deterministically instead of waiting on an event loop that also has to service UI work.

Dynamic webview hibernation

The visual UI only materializes when you open Magic Menu or the manager. When closed, rendering engines hibernate, so the tray process does not carry the GPU, compositor, or renderer overhead that defines an Electron idle footprint.

No background telemetry or sync daemons

Nothing phones home, and nothing syncs in the background. An always-on text expander sees everything you type; Snipset's architecture keeps that trust surface local and keeps the CPU, network, and battery budget yours.

One engine, three platforms

The same Rust engine ships on Windows, Linux, and Android. Because the core is shared and compiled native everywhere, performance characteristics are uniform instead of being re-implemented per platform in different languages.

MEASUREMENT HARNESS

Engine micro-benchmarks

Reproducible in-process timings produced by cargo bench -p snipset --bench perf_report. Reported as p50 / p95 over thousands of iterations.

Measured operationsresults publish after next release run

Snippet match (strict / loose)match_strict · match_loose—µs p50

Trigger scan over snippet cachetrigger_scan—µs p50

Similarity & text post-processingcosine_similarity_1536—µs p50

The harness above measures the real operations the engine performs on every keystroke: matching, trigger scanning, variable rendering and HTML repair. It publishes p50/p95 into the data file that drives this page. Numbers appear here automatically once the release machine has run the benchmark.

COMPETITIVE ADVANTAGE

Where Snipset wins: in architecture, measurement, and ownership

A side-by-side against the five expanders an investor will ask about. Competitor cells come from vendor documentation; Snipset's own cells are from this repository's feature set and its release measurements.

Capability	Beeftext	TextExpander	espanso	Raycast	Alfred	Snipset
Architecture & Data Privacy
Expansion engine	Native (Windows)	App + browser ext (JS)	Rust core	Electron	Native (macOS)	Native Rust, Tauri 2
Data residency	Local	Cloud SaaS sync	Local	Local + cloud	Local (sync opt-in)	100% local SQLite WAL
Typing hot path	No webview	Webview / browser	No webview	Webview	No webview	No webview, no IPC
Telemetry posture	Minimal	Sync telemetry	None	Product telemetry	Opt-in	Zero telemetry, air-gapped
OS coverage	Windows	Windows · macOS · web	Windows · macOS · Linux	macOS	macOS	Windows · Linux · Android
Intelligence & Automation
On-device local AI	—	Cloud API add-on	Community only	Cloud AI	Workflows	Local Ollama, zero cost
Semantic vector search	—	—	—	Cloud search	—	Built-in embeddings
Clipboard history manager	—	—	—	Paywalled	Add-on	Built-in (`Ctrl+]`)
Scripting engine	—	JS (web)	Config DSL	JS/TS ext	Workflows	Embedded Rhai
Pricing & Ownership
Pricing model	Free (OSS)	$40–$120/yr	Free (OSS)	Pro subscription	Powerpack license	One-time lifetime
Offline capability	Full	Degraded offline	Full	Reduced	Full	100% offline
Memory/startup posture	Lean native	Webview runtime	Lean native	Electron runtime	Lean native	Measured per release

Competitor cells reflect vendor documentation and public feature pages as of 2026-09-06and are informative, not adversarially measured. Snipset cells reflect this repository's feature set; its performance claims are restricted to the measured values on this page. See the full feature comparison and the AI & Benchmark page.

METHODOLOGY

How these numbers are produced

Public, reproducible, and re-run on every release, so the data cannot drift from the binary.

Installer size: measured with an HTTP HEAD request against the public update endpoint/api/updater/download/v0.6.780/…, or from the freshly built artifact during release. Source and check date are recorded per value.
Engine micro-benchmarks: compiled with the release profile and run ascargo bench -p snipset --bench perf_report. Each operation reports the p50 and p95 over thousands of iterations, using black-boxed inputs that mirror real snippet caches (10 to 500 snippets).
Process metrics (idle RAM, cold start): sampled on the release machine by scripts/release/measure-performance.ps1. Cold start is measured from OS process creation to tray-and-hooks ready; idle RSS is the Working Set after warm-up. The machine's OS, CPU and RAM are recorded beside the values so version-to-version deltas stay meaningful.
Publication: the three producers are merged into the single data file (apps/website/src/data/performance.json) byscripts/release/generate-performance-data.mjs. This page renders only that file; there is no second source of truth.

Measurement host is recorded and displayed here as soon as the next release run completes.

FAQ

Performance questions, answered plainly

The questions an engineer, or an investor, asks before trusting a benchmark.

These numbers look small. How are they measured without bias?

Every Snipset figure is produced by a reproducible harness, not by hand-written copy. Installer sizes are measured from the live update endpoint; engine timings come from an in-process micro-benchmark (cargo bench --bench perf_report) that reports p50/p95 percentiles over thousands of iterations; process metrics are sampled on a dedicated release machine at tray idle. The full recipe is published on this page and re-run on every release.

Why is the engine match time reported in microseconds?

Snipset expands text without a webview, JavaScript bridge, or network hop between your keystroke and the expansion engine. The typing hot path is pure native code against an in-process SQLite database, so the matching work itself is measured in microseconds. The end-to-end replacement additionally honors your configured erase delay, which is why we report the engine value separately and label it precisely.

Can I reproduce these measurements myself?

Yes. Installer sizes are verifiable with any HTTP client against the public update endpoint listed in the methodology. Engine micro-benchmarks are reproducible with cargo bench -p snipset --bench perf_report from this repository. Process-level sampling is scripted in scripts/release/measure-performance.ps1 for the release machine.

Which hardware were these numbers measured on?

Process-level metrics are always measured on the same dedicated release machine so version-to-version comparisons stay meaningful. The exact OS, CPU, and RAM of that host are recorded into performance.json alongside the numbers, and the page pins both the version and the measurement date.

How often do these numbers get refreshed?

On every release. The measurement pipeline runs during the Windows release build and republishes performance.json automatically, so the page can never drift far from the binary that users actually download. This page always displays the release version and the measurement date that produced each figure.

Why should an investor believe the numbers more than a marketing page?

Because the numbers are not claims: they are outputs. The data file that drives this page is generated by the same release pipeline that builds the product, the methodology is public and reproducible, and any reader can regenerate the figures from source. Disagreeing with the measurement is welcome; disagreeing with the copy is not possible, because there is no invented copy to disagree with.

Ready to Type Less?

Get your license today and reclaim hours of your week.

Get Access Explore Features