[R] How to defeat buffering in Rgui?

[jim holtman]

One of the things that you should learn is how to profile (Rprof) your
code to see where time is being spent.  If you did, you would have
seen that all the time is being spent in 'flush.console'.  As was
pointed out in a previous response, only call it when something is
printed.

  0  31.1 root
  1.   31.1 flush.console
  1.    0.0 %%
  1.    0.0 sin
  1.    0.0 cat

If you modify your code:

for(i in 1:1e4){
   tst <- sin(i)
   if((i%%1e2)==0)cat(i, "")
   if((i%%1e3)==0){cat('\n'); flush.console()}
   # flush.console()
}


You will notice a very large speedup.

  0   0.5 root
  1.    0.4 flush.console
  1.    0.0 cat
  1.    0.0 ==




On Fri, Jun 29, 2012 at 1:15 PM, Spencer Graves
<spencer.graves at structuremonitoring.com> wrote:
> Dear Prof. Ripley:
>
>
>      Thanks for the reply.  Unfortunately, flush.console() seems to lock up
> my system.  I tried the following:
>
>
>
> for(i in 1:1e7){
>    tst <- sin(i)
>    if((i%%1e5)==0)cat(i, "")
>    if((i%%1e6)==0)cat('\n')
>    flush.console()
> }
>
>
>      This slows down Rgui 2.15.1 (32-bit) by a factor of roughly 350:  In
> Rterm (64-bit), on my dual core 64-bit Windows 7 system, this ran to
> completion in 1 minute;  this same code without flush.console() ran to
> completion in 35 seconds in Rgui 2.15.1 (64-bit), then presented the
> display.  Watching it run in Rgui, it seemed to consume roughly half of one
> CPU while making very slow progress.  I started timing it when it displayed
> 200000;  24 minutes later, I noticed it was displaying 900000.  That
> produces an estimate of 340 minutes to complete.
>
>
>      I'd like to use this to give users (e.g., of a CRAN package) a progress
> report on long computations:  Otherwise, a user doesn't know if the
> computation will every complete.
>
>
>      Suggestions?
>
>
>      Thanks,
>      Spencer
>
>
>
> On 6/29/2012 12:12 AM, Prof Brian Ripley wrote:
>>
>> See the posting guide: this is in the FAQ which you are expected to
>> consult before posting. See
>>
>>
>> http://cran.r-project.org/bin/windows/base/rw-FAQ.html#The-output-to-the-console-seems-to-be-delayed
>>
>> and ?flush.console .
>>
>> On 29/06/2012 08:01, Spencer Graves wrote:
>>>
>>> Hello, All:
>>>
>>>
>>>       Does anyone know how to defeat buffering of output to the console
>>> from Rgui?  I routinely print progress reports to the console from
>>> within Rterm running under Emacs with ESS (Emacs Speaks Statistics); see
>>> the example below.  However, when I run the same example under Rgui, it
>>> queues all the output until the computations are complete.
>>>
>>>
>>>       How can I monitor the progress of computations in both Rgui and
>>> Rterm?
>>>
>>>
>>>       Consider the following:
>>>
>>>
>>> for(i in 1:1e7){
>>>     tst <- sin(i)
>>>     if((i%%1e5)==0)cat(i, "")
>>>     if((i%%1e6)==0)cat('\n')
>>> }
>>>
>>>
>>>       For Rterm 2.15.1 running under Emacs with ESS (Emacs Speaks
>>> Statistics), this prints 10000, then pauses before printing 200000,
>>> etc., until it gets to 1000000, printing 10 numbers in each row.
>>>
>>>
>>>       However, in Rgui 2.15.1, it queues all the numbers and prints
>>> them all together when it completes the computation.  The following is
>>> similar:
>>>
>>>
>>> for(i in 1:1e7){
>>>     tst <- sin(i)
>>>     if((i%%1e5)==0)print(i)
>>>     if((i%%1e6)==0)cat('\n')
>>> }
>>>
>>>
>>>> sessionInfo()
>>>
>>> R version 2.15.1 (2012-06-22)
>>> Platform: i386-pc-mingw32/i386 (32-bit)
>>>
>>> locale:
>>> [1] LC_COLLATE=English_United States.1252
>>> [2] LC_CTYPE=English_United States.1252
>>> [3] LC_MONETARY=English_United States.1252
>>> [4] LC_NUMERIC=C
>>> [5] LC_TIME=English_United States.1252
>>>
>>> attached base packages:
>>> [1] stats     graphics  grDevices utils     datasets  methods base
>>>
>>>
>>>       Thanks,
>>>       Spencer
>>
>>
>
> ______________________________________________
> R-help at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.



-- 
Jim Holtman
Data Munger Guru

What is the problem that you are trying to solve?
Tell me what you want to do, not how you want to do it.