#583 switched the macOS export walk to the software H.264 decoder, which runs with thread_count = 0 — every core. It buys a lot of wall clock. It also triples the CPU the export burns, and that was not measured when the change was made. It is now.
One harness run, commons-upload public bundle, S4, Mac mini M1 / macOS 26.5, an ffmpeg floor measured per leg (18 146 / 18 157 ms — 0.06 % apart), every scoring run verified in the pixels:
| build |
cost |
median |
CPU s |
peak RSS |
output |
| patched (#583 + #590) |
1.041× |
18 895 ms |
29.8 |
771 MiB |
57 MB |
| 1.10.0 as shipped |
2.002× |
36 356 ms |
8.4 |
761 MiB |
57 MB |
Wall clock nearly halves; CPU-seconds go up 3.5×. Memory does not move (761 → 771 MiB) and the output is unchanged.
Whether this trade is right is a product question, not a performance one, and it deserves an explicit answer rather than being inherited from a change whose commit message did not mention it:
- For a batch export the user is waiting on, spending idle cores to halve the wait is obviously right.
- On battery it is not obviously right at all, and this was not measured. Three and a half times the CPU-seconds is roughly three and a half times the energy for that stage, minus whatever the shorter run saves elsewhere.
- On a machine already busy — which is where the wall-clock gain matters most — taking every core is also what makes everything else stutter.
Things worth trying, none of them measured yet:
- Lower
thread_count below the core count. The decode was 12–14× faster than VideoToolbox, so there is plenty of headroom to give some back; and the walk is encoder-bound (see the encode-thread issue), so the decoder does not need to be as fast as it can possibly be — only fast enough to stop being the constraint.
- Decide by power source.
powerMonitor.isOnBatteryPower() is already available to the main process and could pick the backend, or a thread count, per export.
The energy figure is the one that would settle it and I did not take it. powermetrics can, and needs sudo, so it was not mine to run.
#583 switched the macOS export walk to the software H.264 decoder, which runs with
thread_count = 0— every core. It buys a lot of wall clock. It also triples the CPU the export burns, and that was not measured when the change was made. It is now.One harness run,
commons-uploadpublic bundle, S4, Mac mini M1 / macOS 26.5, an ffmpeg floor measured per leg (18 146 / 18 157 ms — 0.06 % apart), every scoring run verified in the pixels:Wall clock nearly halves; CPU-seconds go up 3.5×. Memory does not move (761 → 771 MiB) and the output is unchanged.
Whether this trade is right is a product question, not a performance one, and it deserves an explicit answer rather than being inherited from a change whose commit message did not mention it:
Things worth trying, none of them measured yet:
thread_countbelow the core count. The decode was 12–14× faster than VideoToolbox, so there is plenty of headroom to give some back; and the walk is encoder-bound (see the encode-thread issue), so the decoder does not need to be as fast as it can possibly be — only fast enough to stop being the constraint.powerMonitor.isOnBatteryPower()is already available to the main process and could pick the backend, or a thread count, per export.The energy figure is the one that would settle it and I did not take it.
powermetricscan, and needs sudo, so it was not mine to run.