On 30 Nov 2013, at 12:37 , Prof Brian Ripley <[email protected]> wrote:
> This does not happen for me provided R.app is visible. From > > https://developer.apple.com/library/mac/releasenotes/MacOSX/WhatsNewInOSX/Articles/MacOSX10_9.html > > '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 > > (other necessary conditions)'. > > which if accurate indicates that keeping the R.app console unhidden should > suffice. > > Some experimenting indicates that R.app will nap with a partially exposed window, if there is no change to the exposed part of the window. If the top right corner is obscured by the Activity Monitor and I change the test command to not generate output, I see > r <- replicate(50, system.time(replicate(1e4, > t.test(rexp(10),mu=1)$statistic))[["elapsed"]]) > r [1] 5.853 3.607 3.118 3.037 3.012 2.983 2.962 2.978 2.949 2.956 [11] 2.957 19.882 24.386 26.441 25.563 27.452 21.195 20.823 3.012 2.976 [21] 2.965 2.966 2.969 2.945 3.057 2.958 2.942 2.971 2.976 2.936 [31] 2.978 2.960 2.991 2.991 2.994 3.021 2.991 2.974 3.005 2.985 [41] 3.006 2.991 3.033 3.017 2.978 3.012 2.987 2.997 2.995 3.053 (I got bored and woke it after a couple of minutes, at iteration 18). It doesn't happen if it is the bottom right corner that is obscured, so that the spinning "I'm working" symbol is visible, so I suppose the logic is tied to window updates. > > On 30/11/2013 10:59, peter dalgaard wrote: >> >> On 29 Nov 2013, at 16:35 , Simon Urbanek <[email protected]> wrote: >> >>> >>> But let me say that what has been proposed is very heavy-handed to say it >>> mildly - changing user's configuration files is not something that should >>> be done without user's consent (if at all) - and AFAIK you're not allowed >>> to do it if you plan to put this on CRAN. In addition, it's trying to swat >>> the symptom with a hammer, it doesn't solve the problem (which is why >>> doesn't tcltk wake up sleep with its activity). >>> >> >> On the other hand, the OS is also acting very heavy-handed here! Try this >> >>> for (i in 1:100) print(system.time(replicate(1e4, >>> t.test(rexp(10),mu=1)$statistic))[["elapsed"]]) >> >> and go surf the net or something while you wait. The time per iteration >> shoots up by a factor of 5-6 as R.app goes into App Nap. I.e., the problem >> is not confined to tcltk. >> >>> >>>> Wouldn't it be better to handle this issue in R.app or even in tcltk, >>>> however? >>>> >>> >>> Yes, it should be handled in either of the two - if this problem is >>> tcltk-specific then tcltk should wake up the sleep, if it is something that >>> affects other R code as well, then it may need to be handled in the R event >>> loop. >> >> Looks like it is that latter. Until we figure out how to do that, I think we >> need to prepare to tell users to set NSAppSleepDisabled, if they want to do >> something computationally intensive (and be able to go for a cup of coffee >> in the meantime). Of course it is nicer, OS-wise, to leave App Nap enabled, >> but it reduces the energy footprint of an inactive R.app from only about 1.5 >> to nearly 0.0, compared to about 100 when R is actually working. >> > > > -- > Brian D. Ripley, [email protected] > Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ > University of Oxford, Tel: +44 1865 272861 (self) > 1 South Parks Road, +44 1865 272866 (PA) > Oxford OX1 3TG, UK Fax: +44 1865 272595 -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: [email protected] Priv: [email protected] _______________________________________________ R-SIG-Mac mailing list [email protected] https://stat.ethz.ch/mailman/listinfo/r-sig-mac
