emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] Bug? R: Org babel block execution *drastically* slower than in E


From: Aaron Ecay
Subject: Re: [O] Bug? R: Org babel block execution *drastically* slower than in ESS session directly
Date: Sat, 17 Nov 2012 20:41:31 -0500
User-agent: Notmuch/0.14+42~gdb230da (http://notmuchmail.org) Emacs/24.3.50.1 (x86_64-unknown-linux-gnu)

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 “seq” 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’ll see a backtrace that goes
through ‘org-babel-execute:sh’ and then
‘org-babel-import-elisp-from-file’.  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 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’t (at
least not without hacks, such as putting NULL at the end of an R source
block so that the “.Last.value” in the block is trivial).

-- 
Aaron Ecay



reply via email to

[Prev in Thread] Current Thread [Next in Thread]