Both things can be true/desirable at the same time.
If, as tested, this setting makes a double-digit percentage difference, I'm glad Microsoft exposes it in the UI. I'd also be glad if they didn't do as much weird stuff on their user's devices as they do.
> If, as tested, this setting makes a double-digit percentage difference, I'm glad Microsoft exposes it in the UI.
I'd rather them write more performant code. 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.
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".
Better analogy would be reducing your MPGs (fuel efficiency) to show a more precise clock, and arguably we all make that sacrifice to get CarPlay.
Energy isn’t free.
Even if they wrote more performant code, it would just mean less relative loss of energy to show seconds but still loss compared to not showing seconds.
This feels like your car having the option to burn motor oil to show a more precise clock on the dash
I actively don't want to see seconds; the constant updating is distracting. It should be an option even if there were no energy impact. (Ditto for terminal cursor blinking).
I have cursor blinking off anywhere I can. The prompt is what tells me I can type something, or in a GUI program, you can always type if there is a cursor no matter if it's solid or blinking. At least, that's my experience, perhaps you're familiar with another system or piece of software where the blinking is what tells you that you can enter something?
Mentioning that some setting uses more power can be useful and desirable. I think Jaxan might be irked by "energy recommendations" Windows gives you in power & battery settings, though. It suggests applying "energy saving recommendations" to lower your carbon footprint, and while I absolutely support energy saving, I also find those "recommendations" obnoxious.
The recommendations suggest, among other things, switching to power-saving mode, turning on dark mode, setting screen brightness for energy efficiency, and auto-suspending and turning the screen off after 3 minutes.
Power-saving mode saves little at least on most laptops but has a significant performance impact, dark mode only saves power on LED displays (LCDs have a slight inverse effect), and both dark/light mode and screen brightness should be set based on ergonomics, not based on saving three watts.
When these kinds of recommendations are given to the consumer for "lowering your carbon footprint", with a green leaf symbol for impact, while Microsoft's data centres keep spending enormous amounts of power on data analysis, I find it hard to see that as anything more than greenwashing.
The test setting is important here - the test is on an otherwise idle machine. This means that the update ensures that some thread wakes on a timer every second which may explain the large drop. This test is interesting, but not very representative of a real world usage scenario. It’ll be interesting to compare it to the results of the other test they running, where they keep a video running in the background.
I'm still a little curious of what's causing the increase in power use. A single additional wakeup per second should not have a two-digit percentage impact on power use when even an idle machine is probably going to have dozens of wakeups per second anyway. I wonder if updating the seconds display somehow causes lots of extra wakeups instead.
If, as tested, this setting makes a double-digit percentage difference, I'm glad Microsoft exposes it in the UI. I'd also be glad if they didn't do as much weird stuff on their user's devices as they do.