From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aaron Ecay Subject: Re: Bug? R: Org babel block execution *drastically* slower than in ESS session directly Date: Sat, 17 Nov 2012 19:41:33 -0500 Message-ID: <87y5hzg2te.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> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Return-path: Received: from eggs.gnu.org ([208.118.235.92]:50808) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TZsxB-0002lP-7I for emacs-orgmode@gnu.org; Sat, 17 Nov 2012 19:41:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TZsx8-0003yC-52 for emacs-orgmode@gnu.org; Sat, 17 Nov 2012 19:41:41 -0500 Received: from mail-qc0-f169.google.com ([209.85.216.169]:50942) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TZsx7-0003y3-Vo for emacs-orgmode@gnu.org; Sat, 17 Nov 2012 19:41:38 -0500 Received: by mail-qc0-f169.google.com with SMTP id t2so2891547qcq.0 for ; Sat, 17 Nov 2012 16:41:37 -0800 (PST) In-Reply-To: <87obixilbh.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: Eric Schulte , Andreas Leha Cc: emacs-orgmode@gnu.org --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 can= 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 call= 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. (The indentation of the patch as applied isn=E2=80=99t correct =E2=80=93 th= e 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 to a paren in the wrong place. But I cannot see a way to make this approach work.) 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 (~5s= ec on my system). But I chose the value as more of a sanity check =E2=80=93 odds= 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. --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=0001-lisp-ob.el-add-a-size-check-to-org-babel-import-elis.patch >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 scalarize 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 large " + "results may hang emacs; skip " + "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 scalarize it + (if (consp (car result)) + (if (null (cdr (car result))) + (caar result) + result) + (car result)) + result)))))) (defun org-babel-string-read (cell) "Strip nested \"s from around strings." -- 1.8.0 --=-=-= Content-Type: text/plain -- Aaron Ecay --=-=-=--