From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Schulte Subject: Re: Bug? R: Org babel block execution *drastically* slower than in ESS session directly Date: Sat, 17 Nov 2012 17:57:54 -0700 Message-ID: <873907afsd.fsf@gmail.com> References: <874nlappb1.fsf@tajo.ucsd.edu> <878vam1jvh.fsf@tajo.ucsd.edu> <3477.1351723988@alphaville> <11876.1351784283@alphaville> <14621.1351795682@alphaville> <87d2zgrhhr.fsf@gmail.com> <87a9ukr8xy.fsf@gmail.com> <87ehjwa8fg.fsf@med.uni-goettingen.de> <87obixilbh.fsf@gmail.com> <87y5hzg2te.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([208.118.235.92]:35028) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TZtC8-0005dl-Mc for emacs-orgmode@gnu.org; Sat, 17 Nov 2012 19:57:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TZtC5-0007mF-KZ for emacs-orgmode@gnu.org; Sat, 17 Nov 2012 19:57:08 -0500 Received: from mail-ia0-f169.google.com ([209.85.210.169]:41873) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TZtC5-0007m9-Dw for emacs-orgmode@gnu.org; Sat, 17 Nov 2012 19:57:05 -0500 Received: by mail-ia0-f169.google.com with SMTP id r4so3157831iaj.0 for ; Sat, 17 Nov 2012 16:57:04 -0800 (PST) In-Reply-To: <87y5hzg2te.fsf@gmail.com> (Aaron Ecay's message of "Sat, 17 Nov 2012 19:41:33 -0500") 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: Andreas Leha Cc: emacs-orgmode@gnu.org Aaron Ecay writes: > 2012ko azaroak 16an, Eric Schulte-ek idatzi zuen: > >>=20 >> The attached patch adds a "really-silent" results header argument. To >> see the impact compare the running time of the following two code >> blocks. > > Unfortunately, the attached patch doesn=E2=80=99t work correctly. This c= an be > seen by replacing the =E2=80=9Cseq=E2=80=9D command in your examples with= a command that > has side effects =E2=80=93 notify-send, aplay, etc. In the :results none= =E2=80=9D case, > the command is not run at all. > > That=E2=80=99s because the =E2=80=9C(funcall cmd body params)=E2=80=9D ca= ll at l. 574 of ob.el > (patched version) has been put in a branch that is only run if :results > !=3D none. That funcall is responsible for actually evaluating the code > block. > Oh!, thanks for catching this, I just pushed up a fix. > > (The indentation of the patch as applied isn=E2=80=99t correct =E2=80=93 = the two > branches of the if on l. 565 are indented at the same depth as each > other, and as the if. So it=E2=80=99s possible that the problem is due t= o a > paren in the wrong place. But I cannot see a way to make this approach > work.) > Yes, sometimes I find this approach to be preferable to make the diffs more readable and to avoid over-indentation in very large functions. > > The code generating the slowdown is in backend-specific files. So, for > example, a new branch needs to be added to the case statements in > org-babel-R-evaluate(-session), to detect the :results none case and not > read the result. I suspect that each backend will need this treatment > (unless some of them share code). > > In the meantime, attached to this email is a patch that implements a > size check on reading results. If the results file is over 10kb, it > asks the user whether to proceed. You can test this by evaluating: > > #+begin_src sh :results silent > seq 10000 > #+end_src > > 10kb of results actually doesn=E2=80=99t result in a very serious hang (~= 5sec on > my system). But I chose the value as more of a sanity check =E2=80=93 od= ds are > (?) that very few people want to see 10k of results in the (mini)buffer. > The value could be made customizable. > > I also chose the polarity of the y-or-n-p so that picking the default > (yes) option does the sensible thing of not hanging emacs, although it > thus does discard data. I=E2=80=99m not sure which is the worse problem. > I may be outvoted, but I find this approach too be overly complicated. Also, size may frequently not be the best proxy for the time which Emacs will take to ingest the results. Best, > > From 1053f3acfc21f24fc994ae85adff6779838b0ce7 Mon Sep 17 00:00:00 2001 > From: Aaron Ecay > Date: Sat, 17 Nov 2012 19:26:43 -0500 > Subject: [PATCH] lisp/ob.el: add a size check to > `org-babel-import-elisp-from-file' > > Reading large results can cause emacs to hang for a long time. Ask the > user whether to proceed in such cases. > > Signed-off-by: Aaron Ecay > --- > lisp/ob.el | 42 ++++++++++++++++++++++++------------------ > 1 file changed, 24 insertions(+), 18 deletions(-) > > diff --git a/lisp/ob.el b/lisp/ob.el > index bf4b455..b2385e9 100644 > --- a/lisp/ob.el > +++ b/lisp/ob.el > @@ -2462,24 +2462,30 @@ appropriate." > (defun org-babel-import-elisp-from-file (file-name &optional separator) > "Read the results located at FILE-NAME into an elisp table. > If the table is trivial, then return it as a scalar." > - (let (result) > - (save-window-excursion > - (with-temp-buffer > - (condition-case err > - (progn > - (org-table-import file-name separator) > - (delete-file file-name) > - (setq result (mapcar (lambda (row) > - (mapcar #'org-babel-string-read row)) > - (org-table-to-lisp)))) > - (error (message "Error reading results: %s" err) nil))) > - (if (null (cdr result)) ;; if result is trivial vector, then scala= rize it > - (if (consp (car result)) > - (if (null (cdr (car result))) > - (caar result) > - result) > - (car result)) > - result)))) > + (let* ((file-size (nth 7 (file-attributes file-name))) > + (can-load (or (< file-size (* 10 1024)) ; 10kb > + (not (y-or-n-p (concat "Displaying the block's la= rge " > + "results may hang emacs; s= kip " > + "reading them?")))))) > + (when can-load > + (let (result) > + (save-window-excursion > + (with-temp-buffer > + (condition-case err > + (progn > + (org-table-import file-name separator) > + (delete-file file-name) > + (setq result (mapcar (lambda (row) > + (mapcar #'org-babel-string-read= row)) > + (org-table-to-lisp)))) > + (error (message "Error reading results: %s" err) nil))) > + (if (null (cdr result)) ;; if result is trivial vector, then s= calarize it > + (if (consp (car result)) > + (if (null (cdr (car result))) > + (caar result) > + result) > + (car result)) > + result)))))) >=20=20 > (defun org-babel-string-read (cell) > "Strip nested \"s from around strings." > --=20 > 1.8.0 --=20 Eric Schulte http://cs.unm.edu/~eschulte