From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Dokos Subject: Re: Bug? R: Org babel block execution *drastically* slower than in ESS session directly Date: Thu, 01 Nov 2012 14:48:02 -0400 Message-ID: <14621.1351795682@alphaville> References: <874nlappb1.fsf@tajo.ucsd.edu> <878vam1jvh.fsf@tajo.ucsd.edu> <3477.1351723988@alphaville> <11876.1351784283@alphaville> Reply-To: nicholas.dokos@hp.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]:50887) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TTzoE-0001Dt-A6 for emacs-orgmode@gnu.org; Thu, 01 Nov 2012 14:48:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TTzoC-0002DP-R4 for emacs-orgmode@gnu.org; Thu, 01 Nov 2012 14:48:06 -0400 Received: from g1t0027.austin.hp.com ([15.216.28.34]:13290) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TTzoC-0002DA-KC for emacs-orgmode@gnu.org; Thu, 01 Nov 2012 14:48:04 -0400 In-Reply-To: Message from John Hendy of "Thu\, 01 Nov 2012 13\:18\:58 CDT." 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: John Hendy Cc: emacs-orgmode@gnu.org, cberry@tajo.ucsd.edu John Hendy wrote: > On Thu, Nov 1, 2012 at 10:38 AM, Nick Dokos wrote: >=20 > John Hendy wrote: >=20=20=20=20 > > =C2=A0 =C2=A0 o run top (or whatever equivalent is available on you= r OS) and see > > =C2=A0 =C2=A0 =C2=A0 whether the CPU (or one of the CPUs) gets pegg= ed at 100% utilization > > =C2=A0 =C2=A0 =C2=A0 and stays there. If yes, that's an indication = of an infinite loop > > =C2=A0 =C2=A0 =C2=A0 somewhere. > > > > - quit any other instances of emacs/R > > - start `top` in terminal > > - execute block > > - Use '<' '>' to sort back and forth between cpu and ram > > > > Observations > > - R is at 80-100% cpu for about 5sec > > - Then emacs shifts to fairly constant ~100% cpu usage=C2=A0 > > - After about a minute, the minibuffer expands to ~1/3 of the windo= w height and fills with the > csv > > data > > - Finished after ~5min total time > > - So, R took about 5sec, emacs took another 5min to finish > > =C2=A0 > > >=20=20=20=20 > So not an infinite loop. That's progress ;-) >=20=20=20=20 > Perhaps emacs is thrashing? If you are on linux, use swapon -s > or (perhaps better) iostat, or (perhaps even better, at least if > you are on the Gnome 2.x desktop[fn:1]), run the system monitor > applet, click Properties, enable all the monitored resources > (cpu, mem, net, swap, load, disk) and watch it while you are > running the test: in particular, check memory and swap. If you > are swapping even a little bit, that's enough to cause severe > performacne problems[fn:2], which can be cured by using less memory > (so stop any memory hogs from running) or by adding memory. >=20 > Oh, and I'm conscious of R using RAM, so I tried to run this stuff withou= t browsers open, no other R > sessions, etc. Prior to running R and without a browser, I'm typically ar= ound 10-15% RAM utilized... >=20 > I have 4gb, so that should be enough to read this, especially per Chuck's= results! This is also an i7 > work computer. It should fly (and in the ESS session itself, it does). >=20 Check /var/log/syslog (or thereabouts) to see if the kernel is seeing error= s with some blocks on the disk and keeps retrying. Assuming SMART is enabled, run = smartctl -a as well and look for problems. Nick