[R] CPU usage on Windows

Prof Brian Ripley ripley at stats.ox.ac.uk
Mon Mar 19 15:45:09 CET 2007


On Mon, 19 Mar 2007, Jonathan Wang wrote:

> On 3/16/07, Richard M. Heiberger <rmh at temple.edu> wrote:
>> I can't imagine using Windows without Emacs.
>> In particular, the Windows ports of Emacs are very aware
>> of the operating system and usually make the right assumptions.
>>
>> The type of behavior you are noticing can probably be cured by typing C-g in the
>> *R* buffer in emacs.  The most likely cause is that the R process in Emacs
>> is waiting for the plot to finish and is querying the plotting device.
>> Most of that excess CPU usage is from the query loop.  The C-g tells Emacs and R
>> to stop waiting.
>>
>> If C-g doesn't stop the 100% CPU utilization, then it is most likely something
>> about the specific plot you are drawing.  We will need to see a reproducible
>> example to say more.
>
> The behavior I'm seeing is different from what you've described. It's
> reliably reproducible and occurs whenever a plot window is visible,
> whether using ESS & Rterm or Rterm directly. Something as simple as
> plot(1:10, rnorm(10)) will trigger this behavior.
>
> The Windows task manager shows that it's the Rterm process that's
> spinning and not emacs. I've previously observed the behavior you
> mention, where ESS gets stuck in a busy loop waiting for the next
> command prompt from Rterm. This is also (obviously) suboptimal, but
> isn't the particular issue I'm having.
>
> Perhaps it's a graphics driver conflict of some sort?

We don't know, but it is *not* what (almost) everyone else is 
experiencing.  It should go away if you switch off windows() buffering 
(see its help page and option "windowsBuffered").

-- 
Brian D. Ripley,                  ripley at stats.ox.ac.uk
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



More information about the R-help mailing list