How PrayBar was measured

The numbers on praybar.com come from watching PrayBar's process while it sits in the menu bar. Here is how that was done, every run, the raw data, and what the numbers leave out.

PrayBar 1.0

Ten minutes on a MacBook Pro (M1 Pro, 16 GB) running macOS 15.6.1, with PrayBar 1.0 counting down and both notifications on. The menu and Settings stayed closed. This is the build you download.

Average CPU	0.012% (72 ms of CPU time in ten minutes)
Readings at 0.0%	109 of 120
Readings with no CPU at all	76 of 120
Highest reading	0.16%
Memory	11.4–11.6 MiB
Disk writes	0 bytes

Ten of the eleven non-zero readings came in the five seconds after a minute turned, when the countdown changes. The eleventh, at 7:27:21, wasn't on a minute, and its cause wasn't captured. Raw data (CSV).

How

A small sampler, profile-idle.c, asks macOS for PrayBar's process counters every five seconds, the same interval Activity Monitor uses by default. CPU comes from the change in total CPU time between readings, so short bursts between samples still count. As in Activity Monitor, 100% means one full CPU core, and readings are shown to one decimal place.

The sampler was checked against test programs with a known load. It agreed with the kernel's own accounting, as reported by ps, within ps's 0.01-second resolution: 1.69% against 1.72%, and 8.74% against 8.72%.

Every run used an optimized Release build, started outside Xcode. During the idle runs nothing else touched PrayBar, apart from the earliest clock run, where Instruments was also recording.

Every run

The other runs used pre-release builds from the day before 1.0. The earliest of them predate a small optimization to the once-a-minute countdown update. Memory is physical footprint, which is roughly what Activity Monitor's Memory column shows.

Build	Mode	Conditions	Avg CPU	At 0.0%	No CPU	Peak	Memory (MiB)	Data
1.0	Countdown	Idle, 10 min	0.012%	109/120	76/120	0.16%	11.4–11.6	CSV
Pre-release	Countdown	Idle, fresh launch	0.008%	55/60	41/60	0.10%	9.1–9.3	CSV
Pre-release	Countdown	Idle, fresh launch	0.014%	55/60	41/60	0.19%	9.0–9.2	CSV
Pre-release	Clock	Idle, fresh launch	0.0001%	60/60	57/60	0.003%	9.1	CSV
Earlier	Countdown	Idle	0.015%	55/60	39/60	0.20%	9.3–9.5	CSV
Earlier	Clock	Idle, fresh launch	0.0003%	60/60	57/60	0.015%	8.7–8.8	CSV
Earlier	Clock	Idle, after Settings had been opened	0.017%	54/60	42/60	0.40%	29.7–33.5	CSV
Earlier	Countdown	Menu opened once	0.044%	54/60	41/60	1.8%	12.5–13.7	CSV
Earlier	Countdown	Menu and Settings opened	0.19%	50/60	19/60	5.0%	9.5–25.5	CSV

The last two runs weren't idle, and they show what using PrayBar costs. Opening the menu peaks briefly at about 2%. Opening Settings loads SwiftUI, and macOS keeps that in memory after the window closes, so PrayBar settles at about 25–30 MiB instead of 9–12.

Each CSV has one row every five seconds: the time (UTC), total CPU seconds, CPU % for that interval, memory, wakeups and disk I/O. The first row is a baseline.

What these numbers don't cover

Only idle time. Opening the menu or Settings costs more for a moment, as above.
Only PrayBar's own process. Work macOS does on its behalf, such as drawing the menu bar, finding your location and showing notifications, is counted under those system processes.
Short runs. Things that happen a few times a day, like a new prayer time, midnight, waking from sleep or a location refresh, didn't fall inside any run.
CPU time, not energy. Power wasn't measured directly.
One Mac. Expect small differences on yours. Runs on the same Mac varied between 0.008% and 0.015%.

Run it yourself

With PrayBar running and its menu closed, from a clone of the repository:

xcrun clang -O2 scripts/profile-idle.c -o profile-idle
./profile-idle $(pgrep -x PrayBar) 300 > run.csv
python3 scripts/summarize-idle.py run.csv

The second argument is the length of the run in seconds.