Measured August 3, 2026
What it costs to leave running
GFlick is meant to sit in the background for months, so the number that matters is what it consumes while doing nothing. These are complete recordings of operating-system process counters - every metric captured, including the ones where GFlick does not win.
How this was measured
gflick-bench is a native release-mode recorder that reads OS process counters. It does not inject code into the target and does not talk to GFlick over IPC, so it measures both stacks the same way. Each run discards a 120-second warm-up, then samples every two seconds for 30 minutes and writes a versioned JSON report plus a CSV.
Both products are measured as complete products, not as their smallest process: G Hub is recorded as its three resident components together. The primary metric is CPU on a one-core basis - accumulated target CPU time divided by wall time - because it stays comparable across machines with different core counts.
Each result below is one run per stack. The recommended procedure is three alternating runs per stack compared at the median, so treat small differences as provisional.
Windows
GFlick used less of every resource measured.
Environment and scope
| Item | Value |
|---|---|
| Operating system | Windows 10 Pro, build 19045, x86-64 |
| Processor | AMD Ryzen 7 5700X, 8 cores / 16 threads |
| Memory | 32 GB |
| Recorded duration | 1,800 s per recorder, after 120 s warm-up |
| Sample interval | 2 s (900 samples) |
| GFlick group | gflick-agent |
| G Hub group | lghub_agent, lghub_system_tray, lghub_updater |
Target process results
| Metric | GFlick | G Hub | Ratio | Reduction |
|---|---|---|---|---|
| Accumulated CPU time | 1,890 ms | 6,937 ms | 0.272x | 72.8% |
| Average CPU, one-core basis | 0.1050% | 0.3854% | 0.272x | 72.8% |
| Average CPU, whole-system | 0.006562% | 0.024087% | 0.272x | 72.8% |
| CPU sample p95 | 0.8000% | 2.3512% | 0.340x | 66.0% |
| CPU sample maximum | 1.6008% | 10.9055% | 0.147x | 85.3% |
| Resident memory mean | 7.579 MiB | 227.550 MiB | 0.033x | 96.7% |
| Resident memory p95 | 7.590 MiB | 231.418 MiB | 0.033x | 96.7% |
| Virtual memory mean | 1.602 MiB | 287.534 MiB | 0.006x | 99.4% |
| I/O read total | 24,140 B | 20,058,492 B | 0.001x | 99.9% |
| I/O read rate | 13.411 B/s | 11,143.606 B/s | 0.001x | 99.9% |
| I/O write total | 26,962 B | 11,877,360 B | 0.002x | 99.8% |
| I/O write rate | 14.979 B/s | 6,598.533 B/s | 0.002x | 99.8% |
| Resident process count | 1 | 3 | 0.333x | 66.7% |
Validity and observer overhead
| Check | GFlick run | G Hub run |
|---|---|---|
| Matched samples | 900 / 900 | 900 / 900 |
| Missing samples | 0 | 0 |
| Target process start events | 0 | 0 |
| System CPU mean | 8.83% | 8.28% |
| System CPU p95 | 19.57% | 17.30% |
| System CPU maximum | 66.20% | 52.98% |
| Recorder CPU time | 12,984 ms | 12,734 ms |
| Recorder CPU, one-core basis | 0.721% | 0.707% |
Limits of this run
- Both stacks were resident and both recorders sampled concurrently for about 25 minutes 54 seconds, so this is a co-resident comparison, not an isolated sequential A/B test.
- Recorder overhead differed by roughly 2% between runs, which supports the fairness of the process-counter comparison - but recorder CPU exceeded either target's CPU usage.
- Background system load was not perfectly quiet. The G Hub I/O values are Windows all-I/O process counters and are not physical disk traffic alone.
Apple Silicon macOS
GFlick used far less memory and I/O, but slightly more CPU than G Hub.
Environment and scope
| Item | Value |
|---|---|
| Operating system | macOS 15.7.7, build 24G720 |
| Computer | MacBook Air (Mac16,12), Apple M4 |
| Processor | 10 logical cores (4 performance, 6 efficiency) |
| Memory | 16 GB |
| Mouse | PRO X Wireless via USB receiver, 1600 DPI |
| Recorded duration | 1,800 s per recorder, after 120 s warm-up |
| Sample interval | 2 s (900 samples) |
| GFlick group | gflick-agent, gflick-tray |
| G Hub group | lghub_agent, lghub_system_tray, lghub_updater |
Target process results
| Metric | GFlick | G Hub | Ratio | Reduction |
|---|---|---|---|---|
| Accumulated CPU time | 3,621 ms | 3,403 ms | 1.064x | −6.4% |
| Average CPU, one-core basis | 0.2012% | 0.1891% | 1.064x | −6.4% |
| Average CPU, whole-system | 0.020117% | 0.018906% | 1.064x | −6.4% |
| CPU sample p95 | 0.5008% | 0.3003% | 1.668x | −66.8% |
| CPU sample maximum | 9.2546% | 1.1483% | 8.060x | −706.0% |
| Resident memory mean | 34.959 MiB | 258.728 MiB | 0.135x | 86.5% |
| Resident memory p95 | 38.078 MiB | 297.953 MiB | 0.128x | 87.2% |
| Virtual memory mean | 802,945.8 MiB | 804,619.8 MiB | 0.998x | 0.2% |
| I/O read total | 4,096 B | 18,399,232 B | 0.0002x | 99.98% |
| I/O read rate | 2.276 B/s | 10,221.767 B/s | 0.0002x | 99.98% |
| I/O write total | 0 B | 0 B | n/a | n/a |
| Resident process count | 2 | 3 | 0.667x | 33.3% |
Validity and observer overhead
| Check | GFlick run | G Hub run |
|---|---|---|
| Matched samples | 900 / 900 | 900 / 900 |
| Missing samples | 0 | 0 |
| Target process start events | 0 | 0 |
| System CPU mean | 9.89% | 9.34% |
| System CPU p95 | 45.94% | 36.85% |
| System CPU maximum | 76.29% | 55.99% |
| Recorder CPU time | 4,783 ms | 5,602 ms |
| Recorder CPU, one-core basis | 0.266% | 0.311% |
Limits of this run
- This run was sequential, one stack at a time, because starting G Hub immediately changed the live DPI. GFlick was measured from commit 0b648be with the mouse in host/local control.
- Quitting G Hub stopped its agent and tray, but its root-owned updater stayed resident during the GFlick run. That updater is excluded from the GFlick target counters.
- System load was noisier during the GFlick run, and the recorder used more CPU than either target group. macOS virtual-memory figures include large shared mappings and are not physical memory pressure.
What this cannot prove
CPU time, wake frequency, I/O, and memory pressure all influence power draw, but they are not watts. Windows exposes no stable, precise, cross-hardware per-process energy counter suitable for this comparison, so nothing here is a battery-life or power claim.
A real energy result needs these same reports alongside a repeatable whole-system measurement: an external power meter for a desktop, or several long battery-discharge trials for a laptop. The recorder reports its own CPU overhead so that contribution stays visible rather than hidden.
Reproducing it
The recorder ships in the devtools archive and the repository. Build it in release mode, run the binary directly rather than through cargo run so compiler activity does not contaminate the baseline, and record at least three runs per stack with their order alternated.
The full procedure - recommended test conditions, the exact record and compare invocations, and how to read every field in a report - is in the benchmark README .