In keeping with the theme of the comment you're replying to, writing better-performing code and providing performance options are not mutually exclusive. Both are good ideas.
> This feels like your car having the option to burn motor oil to show a more precise clock on the dash; you don't get kudos for adding an off-switch for that.
(Sounds more like you're arguing that it should be forced off instead of being an option? Reasonable take in this case, but not the same argument.)
No, I think they’re arguing that showing seconds in the system tray shouldn’t be so inefficient that turning it off gives back double-digit percentage energy savings.
I think we all agree there needs to be some additional power draw for the seconds feature, but it’s unclear how much power is truly necessary vs this just being a poor implementation.
there's a dramatic increase in how frequently you interrupt the CPU to update the display. That is true at the OS level no matter how efficient you make the second display code.
It shouldn't take any noticable power/cycles to accomplish this task. Having flags for "performance" littered through the codebase and UI is a classic failure mode that leads to a janky slow base performance. "Do always and inhibit when not needed".
In keeping with the theme of the comment you're replying to, writing better-performing code and providing performance options are not mutually exclusive. Both are good ideas.
> This feels like your car having the option to burn motor oil to show a more precise clock on the dash; you don't get kudos for adding an off-switch for that.
(Sounds more like you're arguing that it should be forced off instead of being an option? Reasonable take in this case, but not the same argument.)