From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andreas Leha Subject: Re: Bug? R: Org babel block execution *drastically* slower than in ESS session directly Date: Fri, 16 Nov 2012 18:47:15 +0100 Message-ID: <87obix8mos.fsf@med.uni-goettingen.de> 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: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([208.118.235.92]:53985) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TZQ0u-0000Im-KT for emacs-orgmode@gnu.org; Fri, 16 Nov 2012 12:47:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TZQ0r-0002pJ-Ip for emacs-orgmode@gnu.org; Fri, 16 Nov 2012 12:47:36 -0500 Received: from plane.gmane.org ([80.91.229.3]:38637) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TZQ0r-0002p2-C0 for emacs-orgmode@gnu.org; Fri, 16 Nov 2012 12:47:33 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1TZQ0y-0004SE-D8 for emacs-orgmode@gnu.org; Fri, 16 Nov 2012 18:47:40 +0100 Received: from vpn-2170.gwdg.de ([134.76.2.170]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 16 Nov 2012 18:47:40 +0100 Received: from andreas.leha by vpn-2170.gwdg.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 16 Nov 2012 18:47:40 +0100 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 Hi Eric, Eric Schulte writes: > Andreas Leha writes: > >> tsd@tsdye.com (Thomas S. Dye) writes: >> >>> Aloha Aaron, >>> >>> Welcome to Org-mode. >>> >>> Aaron Ecay writes: >>> >>>> 2012ko azaroak 13an, John Hendy-ek idatzi zuen: >>>> >>>> [...] >>>>> 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? >>>> >>>> “:results silent” just means “silent except for the minibuffer”; IDK >>>> why. >>> >> >> [...] >> >> Just for the record: >> I would also love to see the "really-silent results". >> > > Yes, the existing ":results silent" option still echos the results to > the minibuffer. It was originally added in the case where one does not > want to change the Org-mode buffer (but would still like to see code > block output). > > The attached patch adds a "really-silent" results header argument. To > see the impact compare the running time of the following two code > blocks. > > #+begin_src sh :results really-silent > seq 100000000 > #+end_src > #+begin_src sh :results silent > seq 100000000 > #+end_src > > Before such a patch is applied it would need corresponding > documentation, and the "really-silent" moniker may need to be > reconsidered in favor of something more informative (the main purpose of > this header argument is not silence but is rather avoiding all post > processing), and ideally shorter as well. These new header arguments > are of no value if they are not easily discover-able and easily > remember-able to help others avoid the same issue that launched this > thread. > > Cheers, this is simply great! Thank a lot. I just tested and like it a lot! With respect to the name: I think choosing a new name is hard because it really should be "silent". What is now "silent" would better be named "minibuffer" or sth. similar. But since changing that would break quite some (of my) code, I would suggest simply "none" for the new "really-silent". Just my 2ct. Thanks again. I'll start using it right now. Regards, Andreas