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 20:41:31 -0500 Message-ID: <87sj87g01g.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> <873907afsd.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]:33036) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TZttC-0003sG-CY for emacs-orgmode@gnu.org; Sat, 17 Nov 2012 20:41:41 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TZtt9-00019n-9C for emacs-orgmode@gnu.org; Sat, 17 Nov 2012 20:41:38 -0500 Received: from mail-qa0-f48.google.com ([209.85.216.48]:56056) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TZtt9-00019i-41 for emacs-orgmode@gnu.org; Sat, 17 Nov 2012 20:41:35 -0500 Received: by mail-qa0-f48.google.com with SMTP id s11so3141160qaa.0 for ; Sat, 17 Nov 2012 17:41:34 -0800 (PST) In-Reply-To: <873907afsd.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 2012ko azaroak 17an, Eric Schulte-ek idatzi zuen: > Oh!, thanks for catching this, I just pushed up a fix. This is no longer a (complete) fix for the original problem, though. (A large part of) the slowdown comes from reading the results from a temp file and transforming them into an elispy format, which is handled by the backends. Your code only prevents them from being echoed to the minibuffer. You can see this by trying your original =E2=80=9Cseq=E2=80=9D tests. You = should see them taking the same (very long) amount of time. If you set debug-on-quit to t (before evaluating the block) and interrupt emacs with C-g when it hangs, you=E2=80=99ll see a backtrace that= goes through =E2=80=98org-babel-execute:sh=E2=80=99 and then =E2=80=98org-babel-import-elisp-from-file=E2=80=99. The presence of the fo= rmer in the call stack is why I claim that per-backend fixes are ultimately needed. The latter is where my patch addresses the problem in a temporary way. >=20 > 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. I agree that my patch is a stopgap. But until per-backend fixes are available, this allows certain code to run that otherwise wouldn=E2=80=99t = (at least not without hacks, such as putting NULL at the end of an R source block so that the =E2=80=9C.Last.value=E2=80=9D in the block is trivial). --=20 Aaron Ecay