[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Aaron Ecay
Subject: Re: [O] Bug? R: Org babel block execution *drastically* slower than in ESS session directly
Date: Tue, 13 Nov 2012 22:27:44 -0500
User-agent: Notmuch/0.14+42~gdb230da (http://notmuchmail.org) Emacs/ (x86_64-unknown-linux-gnu)

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.

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.

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
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.

Aaron Ecay

reply via email to

[Prev in Thread] Current Thread [Next in Thread]