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: Sun, 18 Nov 2012 22:11:54 -0700 Message-ID: <87ip92kwh1.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> <87sj87g01g.fsf@gmail.com> <87mwyel799.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]:41670) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TaJdY-0005XL-A0 for emacs-orgmode@gnu.org; Mon, 19 Nov 2012 00:11:15 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TaJdV-0006uM-7p for emacs-orgmode@gnu.org; Mon, 19 Nov 2012 00:11:12 -0500 Received: from mail-ie0-f169.google.com ([209.85.223.169]:61349) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TaJdV-0006uG-28 for emacs-orgmode@gnu.org; Mon, 19 Nov 2012 00:11:09 -0500 Received: by mail-ie0-f169.google.com with SMTP id 10so7632731ied.0 for ; Sun, 18 Nov 2012 21:11:08 -0800 (PST) In-Reply-To: <87mwyel799.fsf@gmail.com> (Eric Schulte's message of "Sun, 18 Nov 2012 18:18:58 -0700") 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: emacs-orgmode@gnu.org Eric Schulte writes: > Aaron Ecay writes: > >> 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. Y= ou 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 t= hat 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= former 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. >> > > I apologize for rushing through your previous email and missing > important portions of the content. > >> >>>=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). > > I'm attaching a new patch which should serve as a more permanent > solution, however, given that it touches almost every backend I want to > give the list a chance to try it out before committing it. This patch > introduces a new macro (`org-babel-result-cond') which attempts to unify > the results processing. Not only does this check for ":results none" > and ignore all results in that case, but it also checks whether the > results should be parsed as a scalar or a vector. Hopefully this will > serve as useful refactoring and reduce the total amount of code as well > as provide for more uniform results processing across languages. > > Please let me know if this looks like a good permanent solution. > > I see that I'm now getting 5 test failures with this patch applied > locally, but I won't have time to look at this further until early next > week at the earliest, so I'm sharing the existing patch now. > > Thanks, Alright, I've now changed the above patch so that as many tests are passing locally as were passing without the patch. Given that, I've applied this patch to the main git repository. Everything which worked previously should still be working, only now the ":results none" options should have the desired effect. Cheers, --=20 Eric Schulte http://cs.unm.edu/~eschulte