Re: [O] Bug? R: Org babel block execution *drastically* slower than in ESS session directly

[Nick Dokos]

John Hendy <address@hidden> wrote:

> On Thu, Nov 1, 2012 at 10:38 AM, Nick Dokos <address@hidden> wrote:
> 
>     John Hendy <address@hidden> wrote:
>    
>     >     o run top (or whatever equivalent is available on your OS) and see
>     >       whether the CPU (or one of the CPUs) gets pegged at 100% 
> utilization
>     >       and stays there. If yes, that's an indication of an infinite loop
>     >       somewhere.
>     >
>     > - quit any other instances of emacs/R
>     > - start `top` in terminal
>     > - execute block
>     > - Use '<' '>' to sort back and forth between cpu and ram
>     >
>     > Observations
>     > - R is at 80-100% cpu for about 5sec
>     > - Then emacs shifts to fairly constant ~100% cpu usage 
>     > - After about a minute, the minibuffer expands to ~1/3 of the window 
> height and fills with the
>     csv
>     > data
>     > - Finished after ~5min total time
>     > - So, R took about 5sec, emacs took another 5min to finish
>     >  
>     >
>    
>     So not an infinite loop. That's progress ;-)
>    
>     Perhaps emacs is thrashing? If you are on linux, use swapon -s
>     or (perhaps better) iostat, or (perhaps even better, at least if
>     you are on the Gnome 2.x desktop[fn:1]), run the system monitor
>     applet, click Properties, enable all the monitored resources
>     (cpu, mem, net, swap, load, disk) and watch it while you are
>     running the test: in particular, check memory and swap. If you
>     are swapping even a little bit, that's enough to cause severe
>     performacne problems[fn:2], which can be cured by using less memory
>     (so stop any memory hogs from running) or by adding memory.
> 
> Oh, and I'm conscious of R using RAM, so I tried to run this stuff without 
> browsers open, no other R
> sessions, etc. Prior to running R and without a browser, I'm typically around 
> 10-15% RAM utilized...
> 
> I have 4gb, so that should be enough to read this, especially per Chuck's 
> results! This is also an i7
> work computer. It should fly (and in the ESS session itself, it does).
> 

Check /var/log/syslog (or thereabouts) to see if the kernel is seeing errors 
with
some blocks on the disk and keeps retrying. Assuming SMART is enabled, run 
smartctl -a
as well and look for problems.

Nick