PDA

View Full Version : App Nap - Reason not to upgrade?


splitpea
Jun 10, 2013, 04:41 PM
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 (http://images.apple.com/osx/preview/docs/OSX_Mavericks_Core_Technology_Overview.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?

cclloyd
Jun 10, 2013, 04:44 PM
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.

splitpea
Jun 10, 2013, 04:58 PM
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.

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).

neilmacd
Jun 10, 2013, 05:07 PM
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.

splitpea
Jun 10, 2013, 05:11 PM
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.

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.

neilmacd
Jun 10, 2013, 05:18 PM
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.

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
Jun 10, 2013, 05:52 PM
http://www.apple.com/osx/preview/advanced-technologies.html

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

splitpea
Jun 10, 2013, 05:59 PM
http://www.apple.com/osx/preview/advanced-technologies.html

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

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.

w0lf
Jun 10, 2013, 06:03 PM
How it works:
An app enters App Nap when it's completely hidden from view, and not actively working.

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.

Knosrac
Jun 10, 2013, 06:30 PM
You guys are overreacting. I promise.

ObeseSquirrel
Jun 10, 2013, 06:44 PM
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.

In your example, the background app would still be actively running. So no problem.

skippymac
Jun 10, 2013, 08:01 PM
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?)

Mr. Retrofire
Jun 10, 2013, 09:12 PM
...
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!
I think HandBrake ignores the Power Management APIs in OS X! So this a HandBrake problem. Do you use the newest version!?

Mr. Retrofire
Jun 10, 2013, 09:28 PM
Apples developer documentation says:
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.
In other words: Application developers can use the new APIs to improve the power efficiency of their apps.

neilmacd
Jun 11, 2013, 09:33 AM
I think HandBrake ignores the Power Management APIs in OS X! So this a HandBrake problem. Do you use the newest version!?

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

splitpea
Jun 11, 2013, 09:52 AM
In your example, the background app would still be actively running. So no problem.

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?

meme1255
Jun 11, 2013, 02:13 PM
Handbrake in last version supports power assertions:
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

SixSlinger
Jul 14, 2013, 06:12 PM
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 (http://images.apple.com/osx/preview/docs/OSX_Mavericks_Core_Technology_Overview.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?

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!

Killa Aaron
Jul 14, 2013, 07:15 PM
It can be turned on or off per app basis, problem Solved!

splitpea
Jul 15, 2013, 06:29 AM
Can be turned on or off per app basis, problem Solved!

Awesome.

nyolc8
Jul 15, 2013, 08:07 AM
It can be turned on or off per app basis, problem Solved!

Did you changed your fonts or something? Because your info panel window have totally different (much lighter) fonts than my.:confused:

pmz
Jul 15, 2013, 09:00 AM
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 (http://images.apple.com/osx/preview/docs/OSX_Mavericks_Core_Technology_Overview.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?


Really? I mean, really?

:confused: Yes, Apple is about to BLOCK background processes with Mavericks. You figured it out.

Killa Aaron
Jul 15, 2013, 09:34 AM
Did you changed your fonts or something? Because your info panel window have totally different (much lighter) fonts than my.:confused:

Yes, I'm using Proxima Nova for my system font.

DoctorFedora
Jul 16, 2013, 12:56 AM
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

gr8tfly
Jul 16, 2013, 01:06 AM
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).

leman
Jul 16, 2013, 08:11 AM
Really? I mean, really?

:confused: Yes, Apple is about to BLOCK background processes with Mavericks. You figured it out.

I actually tested it and it seems that App Nap doesn't apply to a shell script running in a Terminal window, even if its not visible. I guess App Nap only works with applications which explicitly use Cocoa UI APIs.