Aaron Ecay aarone...@gmail.com 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
Eric Schulte schulte.e...@gmail.com writes:
Aaron Ecay aarone...@gmail.com 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
Achim Gratz strom...@nexgo.de writes:
Andreas Leha writes:
I would suggest simply none for the new really-silent.
Yes please, especially since I tried :results none two days ago to
achieve that effect and wondered why it wouldn't work. :-)
Great, since none seems like the obvious choice I
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”
Aaron Ecay aarone...@gmail.com writes:
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
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
Andreas Leha andreas.l...@med.uni-goettingen.de writes:
t...@tsdye.com (Thomas S. Dye) writes:
Aloha Aaron,
Welcome to Org-mode.
Aaron Ecay aarone...@gmail.com writes:
2012ko azaroak 13an, John Hendy-ek idatzi zuen:
[...]
Crazy. I really wondered if it had something to do with trying
Hi Eric,
Eric Schulte schulte.e...@gmail.com writes:
Andreas Leha andreas.l...@med.uni-goettingen.de writes:
t...@tsdye.com (Thomas S. Dye) writes:
Aloha Aaron,
Welcome to Org-mode.
Aaron Ecay aarone...@gmail.com writes:
2012ko azaroak 13an, John Hendy-ek idatzi zuen:
[...]
Crazy.
On Fri, Nov 16, 2012 at 11:47 AM, Andreas Leha
andreas.l...@med.uni-goettingen.de wrote:
Hi Eric,
Eric Schulte schulte.e...@gmail.com writes:
Andreas Leha andreas.l...@med.uni-goettingen.de writes:
t...@tsdye.com (Thomas S. Dye) writes:
Aloha Aaron,
Welcome to Org-mode.
Andreas Leha writes:
I would suggest simply none for the new really-silent.
Yes please, especially since I tried :results none two days ago to
achieve that effect and wondered why it wouldn't work. :-)
Regards,
Achim.
--
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+
SD
Aloha Aaron,
Welcome to Org-mode.
Aaron Ecay aarone...@gmail.com 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
t...@tsdye.com (Thomas S. Dye) writes:
Aloha Aaron,
Welcome to Org-mode.
Aaron Ecay aarone...@gmail.com 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
I just ran into this problem. It is caused by the calls to
‘org-babel-import-elisp-from-file’ on lines 310 and 343 of ‘ob-R.el’
(for non-session and session code blocks respectively). I determined
this by setting ‘debug-on-quit’ to t in Emacs, then hitting C-g when cpu
usage spiked, and
On Tue, Nov 13, 2012 at 9:27 PM, Aaron Ecay aarone...@gmail.com wrote:
I just ran into this problem. It is caused by the calls to
‘org-babel-import-elisp-from-file’ on lines 310 and 343 of ‘ob-R.el’
(for non-session and session code blocks respectively). I determined
this by setting
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.
Are you sure it's only on
On Wed, Oct 31, 2012 at 5:53 PM, Nick Dokos nicholas.do...@hp.com wrote:
John Hendy jw.he...@gmail.com wrote:
On Wed, Oct 31, 2012 at 3:12 PM, cbe...@tajo.ucsd.edu wrote:
John Hendy jw.he...@gmail.com writes:
On Wed, Oct 31, 2012 at 11:41 AM, span dir=ltrmailto:
John Hendy jw.he...@gmail.com wrote:
o run top (or whatever equivalent is available on your OS) and see
whether the CPU (or one of the CPUs) gets pegged at 100% utilization
and stays there. If yes, that's an indication of an infinite loop
somewhere.
- quit any other
On Thu, Nov 1, 2012 at 10:38 AM, Nick Dokos nicholas.do...@hp.com wrote:
John Hendy jw.he...@gmail.com wrote:
o run top (or whatever equivalent is available on your OS) and see
whether the CPU (or one of the CPUs) gets pegged at 100%
utilization
and stays there. If yes,
On Thu, Nov 1, 2012 at 10:38 AM, Nick Dokos nicholas.do...@hp.com wrote:
John Hendy jw.he...@gmail.com wrote:
o run top (or whatever equivalent is available on your OS) and see
whether the CPU (or one of the CPUs) gets pegged at 100%
utilization
and stays there. If yes,
John Hendy jw.he...@gmail.com wrote:
On Thu, Nov 1, 2012 at 10:38 AM, Nick Dokos nicholas.do...@hp.com wrote:
John Hendy jw.he...@gmail.com wrote:
o run top (or whatever equivalent is available on your OS) and see
whether the CPU (or one of the CPUs) gets pegged
John Hendy jw.he...@gmail.com writes:
I edited the subject to be more concise/clear.I let orgmode chug away
on reading in some ~10-30mb csv files for nearly 30min.
[rest deleted]
You need an ECM.
I cannot reproduce your issue.
This runs in the same amount of time, whether I execute the
On Wed, Oct 31, 2012 at 11:41 AM, cbe...@tajo.ucsd.edu wrote:
John Hendy jw.he...@gmail.com writes:
I edited the subject to be more concise/clear.I let orgmode chug away
on reading in some ~10-30mb csv files for nearly 30min.
[rest deleted]
You need an ECM.
I did my best to provide
John Hendy jw.he...@gmail.com writes:
On Wed, Oct 31, 2012 at 11:41 AM, span
dir=ltrmailto:cbe...@tajo.ucsd.edu/span wrote:
John Hendy mailto:jw.he...@gmail.com writes:
I edited the subject to be more concise/clear.I let orgmode chug away
on reading in some ~10-30mb csv files for nearly
On Wed, Oct 31, 2012 at 3:12 PM, cbe...@tajo.ucsd.edu wrote:
John Hendy jw.he...@gmail.com writes:
On Wed, Oct 31, 2012 at 11:41 AM, span dir=ltrmailto:
cbe...@tajo.ucsd.edu/span wrote:
John Hendy mailto:jw.he...@gmail.com writes:
I edited the subject to be more concise/clear.I let
Hi John,
Have you tried wrapping your R read in system.time()? If you are right
about :results silent eating up lots of time, then this should fix the
problem. system.time yields just a bit of output, so shouldn't slow
things down if writing out the data is indeed the problem as you
suspect.
John Hendy jw.he...@gmail.com wrote:
On Wed, Oct 31, 2012 at 3:12 PM, cbe...@tajo.ucsd.edu wrote:
John Hendy jw.he...@gmail.com writes:
On Wed, Oct 31, 2012 at 11:41 AM, span
dir=ltrmailto:cbe...@tajo.ucsd.edu/span wrote:
John Hendy mailto:jw.he...@gmail.com writes:
Thomas S. Dye t...@tsdye.com wrote:
Hi John,
Have you tried wrapping your R read in system.time()? If you are right
about :results silent eating up lots of time, then this should fix the
problem. system.time yields just a bit of output, so shouldn't slow
things down if writing out the
27 matches
Mail list logo
