[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ess-help
Subject:    Re: [ESS] [R] CPU usage on Windows
From:       "A.J. Rossini" <blindglobe () gmail ! com>
Date:       2007-03-19 14:58:19
Message-ID: 1abe3fa90703190758u2cfde3bamf2f10bd3615028f2 () mail ! gmail ! com
[Download RAW message or body]

On 3/19/07, Jonathan Wang <jontwang@gmail.com> wrote:
> On 3/16/07, Richard M. Heiberger <rmh@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?

No, it's some weirdness going on with respect to the different
"threads" and blocking (and from a Ripley-esque perspective, the
intution I'm presenting is technically wrong).  Emacs wants to control
certain things from the I/O perspective, and some how doesn't do it
right, sending Rterm into 100% CPU utilization.

So I think I'm still right, that this is more of an design issue, the
conflicting suspects being Emacs' design for controlling Microsoft OS
subprocesses (emacs inferior process) and R's design as a subprocess
with multiple threads (again, I can't help but think that threads is
the wrong word here, I'm sure Duncan knows the right one to use),
under Microsoft OSs.

 (Duncan took this as a cynical backslap, and I can't stay that I
wasn't partially intending it, but it's also true at face value
without historical baggage of peoples opinions).  And again, at this
point I firmly believe that it's probably more of an ESS/Emacs issue
than a pure R one.

best,
-tony

blindglobe@gmail.com
Muttenz, Switzerland.
"Commit early,commit often, and commit in a repository from which we
can easily roll-back your mistakes" (AJR, 4Jan05).


[prev in list] [next in list] [prev in thread] [next in thread]