Linked by Thom Holwerda on Wed 19th Apr 2017 20:36 UTC

Most people running Windows like having multiple apps running at the same time - and often, what's running in the background can drain your battery. In this latest Insider Preview build (Build 16176), we leveraged modern silicon capabilities to run background work in a power-efficient manner, thereby enhancing battery life significantly while still giving users access to powerful multitasking capabilities of Windows. With "Power Throttling", when background work is running, Windows places the CPU in its most energy efficient operating modes - work gets done, but the minimal possible battery is spent on that work.

My biggest worry with technology like this is that it affects unsaved work. Luckily, you're supposed to be able to turn it on and off.

E-mail Print r 1   9 Comment(s)
Thread beginning with comment 643234
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: Comment by tidux
by grahamtriggs on Thu 20th Apr 2017 14:27 UTC in reply to "RE[2]: Comment by tidux"
Member since:

The priority classes are only going to work if the application detects whether it should be in an idle state, and changes it's priority.

Depending on user permissions, it may not be allowed to change it's priority.

Then you get all sorts of interesting cases - if a window is visible (e.g. it's the only 'application' running), but it doesn't have focus (user has clicked on the explorer, or dismissed an alert) - should that application consider itself a background application or not?

There is an argument that the application should be allowed to know best - but it's also a ton of effort for developers to be building such determination into everything they write.

Having something sensible in the OS that takes that burden from the application developer is a good thing, along with user controls to override if necessary. Possibly even better if there are APIs that let the application take control when the developer knows that is likely to be needed.

Reply Parent Score: 1

RE[4]: Comment by tidux
by Brendan on Fri 21st Apr 2017 02:03 in reply to "RE[3]: Comment by tidux"
Brendan Member since:


I'm not sure where to start here...

An application is not a thread, and the scheduler does not schedule applications. Most threads spend most of their time blocked waiting for something to happen and not running.

A well designed application will have a higher priority thread for "user interface" (its window/s), plus lower priority thread/s for any heavy processing and even lower priority thread/s for any background work. This ensures that the window is "responsive" (e.g. reacts to keyboard and mouse quickly) regardless of how much heavy processing or background work is going on. A higher priority thread for an application's "user interface" is almost always not running (only running for a small amount of time when the user presses a key or clicks the mouse).

When there are no threads running (all threads are blocked waiting for something) and CPU/s are idle, all modern schedulers reduce CPU power consumption, typically in "timed stages" (e.g. drop CPU speed a little after 1 second, drop it down more after 5 seconds, etc).

When the only threads that are running (not blocked waiting for something to happen) are low priority threads, you can drop CPU speed (after a time delay) early; and reduce CPU power consumption when low priority threads are running.

If an OS prevents a thread from reducing its priority for any reason (e.g. user permissions), that OS is a crippled piece of trash. Each thread should have a (potentially "user (mis)configurable") maximum priority and be able to change its current priority to any priority that is below that maximum whenever it likes.

- Brendan

Reply Parent Score: 2