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

[John Hendy <jw.hendy@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2861 bytes --]

On Tue, Nov 13, 2012 at 9:27 PM, Aaron Ecay <aaronecay@gmail.com> wrote:

> I just ran into this problem.  It is caused by the calls to
> ‘org-babel-import-elisp-from-file’ on lines 310 and 343 of ‘ob-R.el’
> (for non-session and session code blocks respectively).  I determined
> this by setting ‘debug-on-quit’ to t in Emacs, then hitting C-g when cpu
> usage spiked, and examining the backtrace.
>
>
Yes! I'm not crazy! I'm not very familiar with the debug options in emacs
and had a heck of a time setting it up right the last time. Thanks so much
for checking this out.


> It seems like Emacs tries to read in the last value of the R command, to
> print it in the minibuffer.  It gets bogged down doing so.  As a
> stopgap, putting NULL as the last line of the source block fixes the
> problem (the value “returned” by the block is just NULL).  I believe
> setting “:results output” (as opposed to “value”) would also make the
> bug disappear, since the output will be very small.  This is likely what
> made cberry’s test differ from John’s.
>
>
Crazy. I really wondered if it had something to do with trying to spit out
the results into the minibuffer. Why is that behavior included?


> I’m not sure what the right strategy would be for a fix.  Two ideas
> would be:
> 1) adding a sanity check to o-b-import-elisp-from-file, which asks the
>    user whether to really import very large files (or just ignores such
>    files)
>

Are you sure it's only on file import? I was generating some large output
when I first experienced this. It was only to avoid running that code that
I wrote it to file once and decided to just read it once per session
afterward (thinking reading would be faster than generating the input on
demand). I was generating a grid of interactions with something akin to:

#+begin_src R
dat <- expand.grid(var1 = seq(0, 40000, by = 200), var2 = seq(0, 40000, by
= 200))
#+end_src

I can check this tomorrow if you'd like, but I remember it lagging as it
tried to print all of that into the minibuffer.


> 2) adding a new :results handling header arg “really-silent” (probably
>    with a better name...) that discards the result entirely, not even
>    printing it to the minibuffer.
>
>
I like this, in addition to changing the minibuffer output as it is. It
would be fantastic to have the minibuffer say more than it does already
(something akin to "Block execution complete"). I have to change to the R
buffer to see if there were any errors. I like how the LaTeX exporter tells
you if PDF export failed. It'd be nice to see something like (in addition
to no results in the minibuffer), "Block execution complete but with
errors."

Thanks again, and I'm glad you were able to track this down.


John


> --
> Aaron Ecay
>

[-- Attachment #2: Type: text/html, Size: 4021 bytes --]