Skip to main content
Lowest input lag is ShareClick’s headline feature. Every design choice defers to it, and we keep a benchmark in the repo so regressions get caught immediately.

​
Measured overhead

Measured on loopback with shareclick bench --encrypted:

~6.5 µs one-way

Transport overhead: serialize + seal + socket + open + deserialize.

~20 ns

Extra cost of encryption (ChaCha20-Poly1305 on tiny packets).
$ shareclick bench --count 20000
METRIC rtt_median_us=~12     # loopback round-trip
METRIC oneway_us=~6          # one-way transport overhead
~6 µs one-way means our code is not the bottleneck. On a real LAN, end-to-end input lag is dominated by the network RTT (~0.2–1 ms) and OS event injection — not ShareClick.

​
Why it’s this fast

A dropped mouse move is irrelevant a millisecond later, so UDP avoids head-of-line blocking. The fast path never waits on retransmits of the slow path. See Decision #1.
An async runtime adds scheduler jitter on the hot path. A dedicated thread with a blocking socket has the most predictable latency — transport.rs is intentionally synchronous. See Decision #3.
High mouse polling rates (1000+ Hz) would flood the network and cause “jumpiness” when polling exceeds display refresh. Coalescing a tick’s events into one packet fixes both. See Decision #6.
transport.rs uses immutable cipher state and no per-packet locks or allocations, precisely to avoid scheduler jitter.

​
Run the benchmark yourself

No OS permissions needed — the benchmark runs entirely on loopback: 
cargo run --release -- bench --count 20000            # plaintext
cargo run --release -- bench --count 20000 --encrypted
Latency is a tracked metric. Before/after any change on the input path, run bench --encrypted and confirm no regression. The history is recorded in autoresearch.jsonl.

​
Next

Architecture

The full dual-channel design behind these numbers.