Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

App Nap - Reason not to upgrade?

S

splitpea

macrumors 65816
Original poster
Oct 21, 2009
1,177
447
Among the starlings
On the one hand, I love the idea of decreasing the CPU usage of background apps (Firefox, I'm looking at you!)

But according to this PDF that someone posted in the news thread, App Nap is something the developer has to explicitly disable, rather than something that has to be explicitly enabled or that the user can opt out of on a per-application basis.

This sounds like a major problem for people who need to do things like running UNIX processes in the background, or running background processing or batch processing in software that predates Mavericks.

Anyone heard anything about a workaround?
 
I'm thinking it's more of a visual freezing than background processes. I seriously doubt it would stop command line things, or torrents in my case, just because you aren't looking at them.
 
cclloyd said:
I'm thinking it's more of a visual freezing than background processes. I seriously doubt it would stop command line things, or torrents in my case, just because you aren't looking at them.
Click to expand...

I hope you're right, because this quote suggests to me that it only doesn't apply if an app is capable of blocking sleep:

App Nap puts applications that you’re not using into a special low-power state that regulates their CPU usage as well as network and disk I/O. App Nap can be automatically triggered if an app’s windows are not visible and the app is not playing audio, though developers can explicitly make an app ineligible for App Nap by using the existing IOKit IOPMAssertion API (used today in OS X to prevent the system from sleeping while an app is busy).
Click to expand...
 
I read the PDF earlier, and have the same concerns. Applications like NZBVortex/Transmission :)o) have had problems in previous OS X updates when Sleep functionality was messed with. Hell, Sleep still ignores my Handbrake encodes! Can see it being the same with App Nap.

Hope it is just a visual thing, but I'm sort of betting against it.
 
neilmacd said:
I read the PDF earlier, and have the same concerns. Applications like NZBVortex/Transmission :)o) have had problems in previous OS X updates when Sleep functionality was messed with. Hell, Sleep still ignores my Handbrake encodes! Can see it being the same with App Nap.

Hope it is just a visual thing, but I'm sort of betting against it.
Click to expand...

I often run scripts on the command line that take half an hour to complete. If this doubles their runtime (or worse), that's a deal breaker for me, and I'll have to invest the time, energy, and money to migrate to some sort of Linux/windows VM combo. Worse workflow, worse hardware, but at least it doesn't make assumptions that all you're doing with your computer is watching cat videos all day.
 
splitpea said:
I often run scripts on the command line that take half an hour to complete. If this doubles their runtime (or worse), that's a deal breaker for me, and I'll have to invest the time, energy, and money to migrate to some sort of Linux/windows VM combo. Worse workflow, worse hardware, but at least it doesn't make assumptions that all you're doing with your computer is watching cat videos all day.
Click to expand...

Wait, what? How did you know? :eek:

I'm sure there'll be a toggle or command line hack to disable it. If it is indeed a problem at all.
 
ObeseSquirrel said:
http://www.apple.com/osx/preview/advanced-technologies.html

It slows the process down without freezing it altogether. So nothing to worry about?
Click to expand...

You're kidding, right?

That would mean that when I'm waiting for a trial to complete, I can either sit there and stare at the log file for 20 minutes, or I can switch windows and do something productive for... How much longer? An hour? Three? ... while waiting for it to complete. Whereas today I can just kick off the job and go do something useful and come back to it and itll be done in that 20 min.

When you have to run that job over and over again several dozen times, with tweaks in between, until you get it right, well, thats a huge blow to productivity.
 
How it works:
An app enters App Nap when it's completely hidden from view, and not actively working.
Click to expand...

I doubt it's going to stop a script from running because it's backgrounded and even if that was the default behavior surely they would have a command just like caffeinate(stop your computer from sleeping while running something) to get around this.
 
splitpea said:
You're kidding, right?

That would mean that when I'm waiting for a trial to complete, I can either sit there and stare at the log file for 20 minutes, or I can switch windows and do something productive for... How much longer? An hour? Three? ... while waiting for it to complete. Whereas today I can just kick off the job and go do something useful and come back to it and itll be done in that 20 min.

When you have to run that job over and over again several dozen times, with tweaks in between, until you get it right, well, thats a huge blow to productivity.
Click to expand...

In your example, the background app would still be actively running. So no problem.
 
Any ideas if things like youtube videos will buffer in browsers when not active? I have horrible internet and if I have to sit and watch videos buffer for hours I won't be happy!

Also, how does it handle minimised windows, fullscreen (not in view) apps and tabs?

(Presumably minimised/fullscreen would enable app nap, but not for individual tabs in a browser?)
 
neilmacd said:
...
Applications like NZBVortex/Transmission :)o) have had problems in previous OS X updates when Sleep functionality was messed with. Hell, Sleep still ignores my Handbrake encodes!
Click to expand...
I think HandBrake ignores the Power Management APIs in OS X! So this a HandBrake problem. Do you use the newest version!?
 
Apples developer documentation says:
Apple said:
Major Features

The following sections highlight OS X v10.9 features that span multiple technology areas or that are otherwise of particular importance to most developers.


App Nap

App Nap reduces power consumption by completely suspending your app’s execution when it meets certain criteria. This ensures that your app does not periodically wake up to do unnecessary work. An app is considered to be a candidate for sleep if:
• It is not visible—if all of an app’s windows are either hidden by other windows or minimized in a hidden dock, and the app is not in the foreground
• It is not audible
• It has not explicitly disabled automatic termination
• It has not taken any power management assertions
When all of these conditions are met, OS X may put the app to sleep. While asleep, the app is placed on a scheduling queue that rarely gets actual time on the CPU.
The app wakes up automatically when the user brings the app to the foreground or when the app receives a Mach message or Apple event.
To support activities that should not be suspended, the NSProcessInfo class has three new methods—beginActivityWithOptions:reason:, endActivity:, and performActivityWithOptions:reason:block:—to tell OS X that your app is actively doing something important. These methods do two things:
• Allow your app to temporarily suspend idle sleep, display sleep, sudden termination, and automatic termination for the duration of a particular operation
• Allow your app to temporarily increase the scheduler timer precision while your app is performing latency-critical operations
Note:*If you experience problems with App Nap, you can temporarily disable it for a particular process by typing:

defaults write <app domain name> NSAppSleepDisabled -bool YES

Immediately file a bug describing the app and explaining how to reproduce the problem.


For more information, see Foundation Release Notes for OS X v10.9.
Click to expand...
In other words: Application developers can use the new APIs to improve the power efficiency of their apps.
 
Mr. Retrofire said:
I think HandBrake ignores the Power Management APIs in OS X! So this a HandBrake problem. Do you use the newest version!?
Click to expand...

Oh it's definitely a HandBrake problem. I always forget to extend sleep time when encoding, come back an hour later and it's stopped at 2% :D
 
ObeseSquirrel said:
In your example, the background app would still be actively running. So no problem.
Click to expand...

I really, really, hope you're right. But how does the kernel know what's "actively running" if the window isn't foregrounded? The docs suggest that the only way to be sure is by using that particular API. But what if it's an app written 2 years ago? What if it's a shell script?
 
Handbrake in last version supports power assertions:
Code: 
 pmset -g assertions
11.06.13 21:12:00 GMT+02 
Assertion status system-wide:
   PreventUserIdleDisplaySleep    0
   PreventSystemSleep             0
   PreventUserIdleSystemSleep     1
   ExternalMedia                  0
   UserIsActive                   0
   ApplePushServiceTask           0
   BackgroundTask                 1

Listed by owning process:
  pid 98945(HandBrake): [0x0000000100002498] 00:00:02 NoIdleSleepAssertion named: "HandBrake is currently scanning and/or encoding" 
  pid 40(mDNSResponder): [0x000000010000016e] 119:53:34 NoIdleSleepAssertion named: "mDNSResponder.40 vnic0 does not support NetWake" 
  pid 103(coreaudiod): [0x0000000100002435] 00:46:00 NoIdleSleepAssertion named: "com.apple.audio.'AppleHDAEngineOutput:8,0,1,2:0'.noidlesleep" 
  pid 98939(helpd): [0x0000000c00002496] 00:00:22 BackgroundTask named: "com.apple.helpd.sdmbuilding" 

Kernel Assertions: 0x0396
 
splitpea said:
On the one hand, I love the idea of decreasing the CPU usage of background apps (Firefox, I'm looking at you!)

But according to this PDF that someone posted in the news thread, App Nap is something the developer has to explicitly disable, rather than something that has to be explicitly enabled or that the user can opt out of on a per-application basis.

This sounds like a major problem for people who need to do things like running UNIX processes in the background, or running background processing or batch processing in software that predates Mavericks.

Anyone heard anything about a workaround?
Click to expand...

Don't worry...App Nap is completely dynamic, so there is no possibility of OS X ignoring an App or not providing resources.

In it's simplest form, here's how App Nap works: If an Application doesn't request system resources (a threshold set by Apple) for a period of time, it enters App Nap. The App is still running, still open and still fully functional. If the Application requests system resources (network, CPU, GPU, RAM, etc), App Nap is disabled.

It's completely seamless and works completely within the RAM. Higher RAM machines will be able to take advantage of App Nap to a greater degree than lower RAM machines, although the new memory compression algorithms in Mavericks will make 4GB feel like 8GB in Mountain Lion.

Hope this helps a little!
 
It can be turned on or off per app basis, problem Solved!
 

Attachments

  • Screen Shot 2013-07-14 at 7.14.25 PM.png
    Screen Shot 2013-07-14 at 7.14.25 PM.png
    104.4 KB · Views: 607
Last edited:
splitpea said:
On the one hand, I love the idea of decreasing the CPU usage of background apps (Firefox, I'm looking at you!)

But according to this PDF that someone posted in the news thread, App Nap is something the developer has to explicitly disable, rather than something that has to be explicitly enabled or that the user can opt out of on a per-application basis.

This sounds like a major problem for people who need to do things like running UNIX processes in the background, or running background processing or batch processing in software that predates Mavericks.

Anyone heard anything about a workaround?
Click to expand...


Really? I mean, really?

:confused: Yes, Apple is about to BLOCK background processes with Mavericks. You figured it out.
 
guys guys i just thought of a very obvious usage case that wasn't explicitly addressed by apple

there's no chance that apple thought of this very obvious usage case though as demonstrated through evidence that they didn't mention it specifically

everyone let's have a contest to see who can scream and crap their pants the fastest
 
OP: watch the WWDC video on App Nap and/or the dev documentation. You can sign up for a free dev account, if you need to, to access the videos and docs. Some of the other energy and performance subjects are also interesting.

Anyway, as some others are posting, if an app needs to be doing work in the background, it will get the resources needed. AppNap doesn't simply suspend background apps. The Mavericks Core Technogies Overview lists a few of the major features, but there's much more to it than can be covered in the overview.

If, for some reason, an app that doesn't use the new API misbehaves, there's the option to disable all App Nap functionality for that app (just as there are options to run in 32-bit mode, or low resolution, for instance).
 
Last edited:
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back