From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Hendy Subject: Re: Bug? R: Org babel block execution *drastically* slower than in ESS session directly Date: Tue, 13 Nov 2012 22:52:14 -0600 Message-ID: References: <874nlappb1.fsf@tajo.ucsd.edu> <878vam1jvh.fsf@tajo.ucsd.edu> <3477.1351723988@alphaville> <11876.1351784283@alphaville> <14621.1351795682@alphaville> <87d2zgrhhr.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=14dae93a148d607c9104ce6d4c99 Return-path: Received: from eggs.gnu.org ([208.118.235.92]:36364) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TYUxX-0005Vv-GA for emacs-orgmode@gnu.org; Tue, 13 Nov 2012 23:52:22 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TYUxU-0000a9-Dw for emacs-orgmode@gnu.org; Tue, 13 Nov 2012 23:52:19 -0500 Received: from mail-oa0-f41.google.com ([209.85.219.41]:65084) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TYUxU-0000a5-40 for emacs-orgmode@gnu.org; Tue, 13 Nov 2012 23:52:16 -0500 Received: by mail-oa0-f41.google.com with SMTP id k14so40578oag.0 for ; Tue, 13 Nov 2012 20:52:15 -0800 (PST) In-Reply-To: <87d2zgrhhr.fsf@gmail.com> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: nicholas.dokos@hp.com, John Hendy , emacs-orgmode@gnu.org, cberry@tajo.ucsd.edu --14dae93a148d607c9104ce6d4c99 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Nov 13, 2012 at 9:27 PM, Aaron Ecay wrote: > I just ran into this problem. It is caused by the calls to > =E2=80=98org-babel-import-elisp-from-file=E2=80=99 on lines 310 and 343 o= f =E2=80=98ob-R.el=E2=80=99 > (for non-session and session code blocks respectively). I determined > this by setting =E2=80=98debug-on-quit=E2=80=99 to t in Emacs, then hitti= ng 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 =E2=80=9Creturned=E2=80=9D by the block is just NULL).= I believe > setting =E2=80=9C:results output=E2=80=9D (as opposed to =E2=80=9Cvalue= =E2=80=9D) would also make the > bug disappear, since the output will be very small. This is likely what > made cberry=E2=80=99s test differ from John=E2=80=99s. > > 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=E2=80=99m not sure what the right strategy would be for a fix. Two ide= as > 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 =3D seq(0, 40000, by =3D 200), var2 =3D seq(0, 4000= 0, by =3D 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 =E2=80=9Creally-silent=E2=80= =9D (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 > --14dae93a148d607c9104ce6d4c99 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Nov 13, 2012 at 9:27 PM, Aaron Ecay <aaronecay@gmail.com&g= t; wrote:
I just ran into this problem. =C2=A0It is caused by the calls to
=E2=80=98org-babel-import-elisp-from-file=E2=80=99 on lines 310 and 343 of = =E2=80=98ob-R.el=E2=80=99
(for non-session and session code blocks respectively). =C2=A0I determined<= br> this by setting =E2=80=98debug-on-quit=E2=80=99 to t in Emacs, then hitting= C-g when cpu
usage spiked, and examining the backtrace.


Yes! I'm not crazy! I'm not ve= ry familiar with the debug options in emacs and had a heck of a time settin= g it up right the last time. Thanks so much for checking this out.
=C2=A0
It seems like Emacs tries to read in the last value of the R command, to print it in the minibuffer. =C2=A0It gets bogged down doing so. =C2=A0As a<= br> stopgap, putting NULL as the last line of the source block fixes the
problem (the value =E2=80=9Creturned=E2=80=9D by the block is just NULL). = =C2=A0I believe
setting =E2=80=9C:results output=E2=80=9D (as opposed to =E2=80=9Cvalue=E2= =80=9D) would also make the
bug disappear, since the output will be very small. =C2=A0This is likely wh= at
made cberry=E2=80=99s test differ from John=E2=80=99s.


Crazy. I really wondered if it had som= ething to do with trying to spit out the results into the minibuffer. Why i= s that behavior included?
=C2=A0
I=E2=80=99m not sure what the right strategy would be for a fix. =C2=A0Two = ideas
would be:
1) adding a sanity check to o-b-import-elisp-from-file, which asks the
=C2=A0 =C2=A0user whether to really import very large files (or just ignore= s such
=C2=A0 =C2=A0files)

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

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

I can check this tomorrow if you'd lik= e, but I remember it lagging as it tried to print all of that into the mini= buffer.
=C2=A0
2) adding a new :results handling header arg =E2=80=9Creally-silent=E2=80= =9D (probably
=C2=A0 =C2=A0with a better name...) that discards the result entirely, not = even
=C2=A0 =C2=A0printing 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 ho= w the LaTeX exporter tells you if PDF export failed. It'd be nice to se= e 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 t= his down.


John
=C2=A0
--
Aaron Ecay

--14dae93a148d607c9104ce6d4c99--