What does a little rain cost?
Measured September 28, 2026 · Apple M4 Max · One built-in display
Weatherling draws moving rain around your windows, so it uses CPU time, GPU work, and memory while it runs. People have asked how much. Here is how I measure it, what the latest run found, and what I still need to test.
On this Mac, the two valid short default runs averaged 2.97–3.75% of one CPU core and 375–391 MiB of physical memory. The four-hour run used more memory over time, reaching about 467 MiB before settling during its final hour. These are measurements of one build on one machine, not a promise about every Mac or about battery life.
The Mac and build I tested
This run used a MacBook Pro with an Apple M4 Max, 64 GB of memory, and macOS 27.0. Its built-in display was 3456 × 2234 pixels at 2× scale, with a reported 120 Hz refresh rate. The Mac was plugged into AC power. Automatic brightness stayed on, and normal desktop work continued with nine visible windows at the start. It was not an isolated, idle laboratory desktop.
The app was a local Release build labeled 1.3 (build 3), based on commit 0ed73f4 with additional local audio and input-tracing changes recorded alongside the test. A Release build uses production compiler optimizations; it does not mean this exact executable is the version currently available on the App Store. I froze a copy before collecting data so later code changes could not replace the executable under test.
How a benchmark run works
I measure the native app drawing rain on the desktop. A browser animation, screenshot, or offscreen rendering test cannot tell me the whole cost of keeping a live overlay among open windows. Temporary settings make each phase repeatable without overwriting the user’s preferences.
- Start with the app quit. Record a one-minute system baseline, then launch the app with rain off. Give it 30 seconds to settle and sample for three minutes.
- Run default rain. Use intensity 0.35, Automatic quality at 30 fps, fixed wind and depth, with sound and near-camera particles off. Warm up for two minutes, then measure for ten.
- Run heavy rain. Use maximum intensity, Smooth quality at 60 fps, near-camera particles, and sound. Again, warm up for two minutes and measure for ten.
- Repeat three times. Repeated rounds show variation that a single favorable number would hide. Finish with another app-quit baseline.
- Leave default rain running for four hours. After a fresh warm-up, track memory and CPU throughout the longer session, including the trend near its end.
The full sequence takes about five and a half hours. The test harness keeps the display awake, and the temporary presets allow rain over full-screen apps. Those are measurement conditions, not evidence about the app’s normal sleep behavior. Separate GPU traces, network observations, and a memory-map snapshot run outside the CPU and memory sampling windows. I check the logs for pauses, unexpected exits, and profiler overlap before accepting a result.
The latest results
| Scenario | Completed samples | Mean CPU | Mean physical memory |
|---|---|---|---|
| Rain off, fresh launch | 3 × 3 minutes | 0.23–0.82% | 26.0–26.4 MiB |
| Default rain, 30 fps | 2 valid × 10 minutes | 2.97–3.75% | 375.0–390.5 MiB |
| Heavy rain, 60 fps | 3 × 10 minutes | 6.17–10.01% | 411.7–419.3 MiB |
| Default rain, endurance | 4 hours | 5.64% | 441.5 MiB |
CPU percentages use one core as 100%, not the entire processor. Memory is physical footprint, which includes graphics accounting; it is not the smaller resident-memory number sometimes shown by other tools. Rain-off results are fresh disabled launches, not memory retained after switching an active effect off.
The first default round was conservatively excluded: an excluded-app rule paused rain near the end of warm-up, and screenshot-tool activity crossed the sampling boundary. All phases finished, but I obtained only two clean short default rounds. Heavy CPU also varied substantially between rounds. Changing desktop activity makes it hard to attribute that variation to Weatherling alone.
Why I leave it running for four hours
A ten-minute test can miss allocations that accumulate later. During endurance, physical memory rose from 379.9 to 467.1 MiB, with a sampled peak of 469.7 MiB. The hourly averages were 421.0, 435.0, 442.8, and 467.0 MiB. The final hour was nearly flat: its fitted trend was about +0.1 MiB per hour.
That late plateau is useful evidence, but it does not prove there are no leaks. The earlier growth still merits investigation. Mean CPU over the four hours was 5.64% of one core; the 95th percentile was 12.15%, meaning 95% of sampled intervals were at or below that level. No lifecycle pause was logged during endurance. Repeated toggling, display reconnects, and sleep/wake cycles need separate tests.
GPU work and smoothness
Separate Metal System Trace recordings observed about 30 presentation callbacks per second at default quality and 60 at heavy quality. Mean / 95th-percentile active GPU time per command buffer was 0.307 / 0.758 milliseconds for default and 0.375 / 0.596 milliseconds for heavy. For context, a frame at 30 fps has a 33.3 ms budget; at 60 fps it has 16.7 ms.
Each trace covered about 31 seconds. There was one callback gap over 50 ms in default and 15 over 25 ms in heavy. These callbacks help describe pacing, but they are not direct display latency or an exact count of dropped frames. GPU execution time is also not a GPU-utilization percentage. I keep the profiler’s own overhead separate from the longer CPU and memory measurements.
What about battery life?
This run cannot answer how many minutes Weatherling takes off a battery charge. I collected system power estimates during the short rounds and observed WindowServer, the macOS process that composites the desktop. Those readings include other apps and changing desktop work. Subtracting one busy-system reading from another would not produce a reliable app-only wattage.
Power recording began partway through the first disabled-app phase and ended early in endurance. The initial quit baseline and most of the four-hour phase therefore have no power samples. A useful battery-life claim needs controlled unplugged testing, consistent brightness and workload, and comparisons with the app both running and quit. I have not completed that test here.
How I keep the measurements honest
The CPU sampler reads macOS process counters, with its time conversion checked against a process CPU clock. It samples physical memory and disk I/O about every two seconds. I save the executable hash, app version, source state, settings, timestamps, and lifecycle logs so a result can be traced back to the run that produced it. Profiling finished before the measured windows in this run, and the saved settings were unchanged afterward.
Short network snapshots are only observations during those windows; an empty snapshot is not proof of a lifetime networking guarantee. Similarly, zero physical disk writes would not mean zero logical file activity. I retain raw traces locally because they can contain information about other processes on the test Mac. This page publishes the aggregate findings and conditions.
I still need measurements on less powerful Macs, external displays, battery power, Low Power Mode, and systematic sleep and display transitions. This run also does not isolate the cost of individual Lings. Future measurements will use the same sequence where possible, with changes in hardware, settings, and build called out rather than blended into one headline number.
If performance feels different on your Mac, send a report with your Mac model, app version, display setup, and rain settings. Those details help turn a general concern into a test I can repeat.