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 2.2.1/Cocoa - internal editor cpu/mem leaks; external editor call doesn't work
2 messages · JBThiel, Rob Goedman
1 day later
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