[R-SIG-Mac] R 2.2.1/Cocoa - internal editor cpu/mem leaks; external editor call doesn't work

[Rob J Goedman]

John,

Thanks very much for the feedback.

Which version of R.app are you using?

I have tried some of your steps on MAC OS X 10.4.5 with R 2.2.1 and
R.app v 1.14 (2298).

> * The R internal editor rails the cpu to 100% when open, even when it
> is just sitting in the background -- probably is using polling.

On my system, with menumeters on, typically the load is 10%/5%
when the system is idle with just R running. If I open, say through open
file in the menu, an (internal) editor window, the load goes up for a  
second or
so ( e.g. 36%/18%) and than falls back to above numbers. Same for the  
next
set of additional edit windows (I've tried up to 10 simultaneous windows
this morning).

If I open the internal editor using fix or edit(functionname) the  
load will stay up
higher (e.g., I've seen 60%/14%) while R is kept 'waiting'.

My system is a powerbook G4, guess above numbers will be slightly  
different
for other systems, but on my G5 they are similar.

> * Editing via external editor does not seem to work.  The fix() call
> invokes the external application, but returns immediately.

Which is the documented behavior for the external editor (section  
4.4.6 of
the FAQ for R on Mac OS). How I use it is to source the file back to  
R after
I make edits (using AppleScript). For fix() and edit() you will have  
to insert
the 'functionname <-' before sourcing it back to R. Which I think is ok,
usually I end up saving the edited file anyway.

I think the 1st step should be to compare the cpu usage and then look
into the memory issues. In your examples below, do you start/stop the  
editor
using edit/fix 10s, 100s or 1000s of times before you see a noticeable
difference?

Rob

On Feb 16, 2006, at 7:45 PM, JBThiel wrote:

> R 2.2.1   on OS X  10.4.3   (also seen on OS X 10.3.9)
> via the Cocoa GUI:
>
>
> * The R internal editor rails the cpu to 100% when open, even when it
> is just sitting in the background -- probably is using polling.
>
> * There appears to be a memory leak with the internal editor, whereby
> every time the editor is loaded and exited, the R app consumes at
> least 1.2MB of additional memory, and fails to release it.   A simple
> cycle of:
> 	loop:
> 		fix(abc)
> 		close the edit window
>
> will apparently increase the R real memory allocation without bound.
>
>
> * Possibly related to the above, as the internal editor is invoked
> repeatedly over time, it takes increasingly longer to load the edit
> window.
>
>
> * We have also observed a condition where simply mouse-click
> switching between the Rconsole window and another R window containing
> a displayed graph - but not actually doing anything other than
> clicking back and forth,  increases the R real memory usage by
> 10-20KB on each series of clicks.
>
> * Editing via external editor does not seem to work.  The fix() call
> invokes the external application, but returns immediately.  The
> external editor starts up fine, and sees the tempfile, but any
> editing done to it is never seen  (since the fix() has already
> returned).   Tested with editors like TextWrangler, Smultron,  
> TextEdit.
>
>
> These bugs make it problematic to run long R sessions with heavy
> editing, as the R session starts to drag more and more   (and can
> induce other application (possibly even system) crashes as other apps
> fail to run in the diminishing memory space).
>
> Thanks for your great work on the Cocoa R, which is extremely useful
> to us.
>
> Best regards,
>
> John
>
> _______________________________________________
> R-SIG-Mac mailing list
> R-SIG-Mac at stat.math.ethz.ch
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac