3 ms·
> I'd rather them write more performant code. In keeping with the theme of the comment you're replying to, writing better-performing code and providing perform
by minitech 1y ago
> I'd rather them write more performant code.
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.)
- jjj123 1y agoNo, 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.
- ants_everywhere 1y agothere'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.
- troupo 1y agoHow about web views throughout the OS? The new start menu written in React? There's an ungodly amount of CPU and GPU spikes throughout the OS which make the "omg seconds" invisible in comparison
- morganherlocker 1y agoIt 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".