2012ko azaroak 16an, Eric Schulte-ek idatzi zuen:

> 
> 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’t work correctly.  This can be
seen by replacing the “seq” command in your examples with a command that
has side effects – notify-send, aplay, etc.  In the :results none” case,
the command is not run at all.

That’s because the “(funcall cmd body params)” call at l. 574 of ob.el
(patched version) has been put in a branch that is only run if :results
!= none.  That funcall is responsible for actually evaluating the code
block.

(The indentation of the patch as applied isn’t correct – the two
branches of the if on l. 565 are indented at the same depth as each
other, and as the if.  So it’s 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’t result in a very serious hang (~5sec on
my system).  But I chose the value as more of a sanity check – 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’m not sure which is the worse problem.