Skip to content

Windows Rgui.exe 4.2.0: Call of txtProgressBar() slows down dramatically after subsequent calls

4 messages · Tobias Schoch, Paulo Barata, Tomas Kalibera

Original
Tobias Schoch
# 
The issue appears in Rgui.exe version 4.2.0 (called "new" version; see bottom). The issue does NOT appear with Rterm.exe (same R version).

I provide a minimal example (foo) below. If I run function foo 3 times in a row, the execution time increases considerably (although it should not).

1st foo call: 5 seconds
2nd foo call: 13 seconds
3rd foo call: 20 seconds

The execution time keeps increasing when I call foo more often. In addition, Rgui.exe becomes laggy in taking input from the keyboard.

Sometimes, but rarely, I observe that Rgui.exe terminates with "Error: C stack usage is too close to the limit". Unfortunately, I cannot reproduce the stack error consistently.

On the "old" Rgui.exe version 4.1.2, execution time stays roughly constant over consecutive calls of foo (as expected). Unfortunately, I do not have a running 4.1.3 version; thus, I cannot tell how it behaves there.

Do you have any clue why this happens?

Kind regards,
Tobias


#------------------------------
# minimal working example: interestingly, the issue does not occur
# when 'style = 1' in txtProgressBar()
foo <- function(n)
{
    p_bar <- txtProgressBar(style = 3)
    for (i in 1:n) {
        Sys.sleep(0.01)
        setTxtProgressBar(p_bar, i / n)
    }
    close(p_bar)
}
# 1st call
system.time(foo(100))
# 2nd call
system.time(foo(100))
# 3rd call
system.time(foo(100))
#------------------------------


My R versions: 

"Old" Rgui.exe
    R version 4.1.2 (2021-11-01)
    Platform: x86_64-w64-mingw32/x64 (64-bit)
    Running under: Windows 10 x64 (build 19044)

"New" Rgui.exe
    R version 4.2.0 (2022-04-22 ucrt)
    Platform: x86_64-w64-mingw32/x64 (64-bit)
    Running under: Windows 10 x64 (build 19044)


------------------------------------------------------------------
Fachhochschule Nordwestschweiz FHNW 
Hochschule f?r Wirtschaft 
Institute for Competitiveness and Communication
Empirische Wirtschafts- und Sozialforschung

Prof. Dr. Tobias Schoch
Riggenbachstrasse 16
CH-4600 Olten
Schweiz / Switzerland
------------------------------------------------------------------
T +41 62 957 21 02
Mail tobias.schoch at fhnw.ch
http://www.fhnw.ch/de/personen/tobias-schoch
Paulo Barata
# 
There runs of Tobias' foo function on different versions of R that I 
have installed here.

R version 4.1.1 Patched (2021-09-30 r80997)
elapsed time of three trials: 1.31 / 1.33 / 1.35

R version 4.1.2 Patched (2021-11-02 r81131)
elapsed time of three trials: 1.34 / 1.34 / 1.34

R version 4.1.3 Patched (2022-03-10 r81878)
elapsed time of three trials: 1.33 / 1.34 / 1.37

R version 4.2.0 Patched (2022-05-17 r82371 ucrt)
elapsed time of three trials: 7.14 / 17.56 / 27.21

Platform is always: x86_64-w64-mingw32/x64 (64-bit)
RGui.exe running on Windows 10 Professional 64-bit (build 19044.1706)

Not only, as Tobias has shown, there is an increasing time among the 
three trials in R 4.2.0 Patched, but also the average time for each of 
the 4.1.X Patched versions (with nearly constant time each) is well 
smaller than the first trial with R 4.2.0 Patched.

Regards,

Paulo Barata

(Rio de Janeiro - Brazil)

----------------------------------------------------------
On 19/05/2022 15:37, Tobias Schoch wrote:
Tomas Kalibera
#
On 5/19/22 22:34, Paulo Barata wrote:
Thanks, yes, I can reproduce the problem. Changing the implementation of 
the progress bar to print "\n" instead of "\r" makes the problem go away 
(and type=2 and 3 have the problem and use \r, while type=1 doesn't have 
the problem nor uses \r). Perhaps the carriage return is not interpreted 
correctly and the line somehow internally keeps the previously printed 
characters, always adding the new ones at the end. That is also 
consistent with that the time is increasing linearly. I will investigate 
further.

Best
Tomas
Tomas Kalibera
#
On 5/19/22 23:18, Tomas Kalibera wrote:
Now fixed in R-devel and R-patched (revision >= 82389 of R-patched).

It turns out that Rgui always keeps a buffer of all the text including 
the \r, but the overhead was poor performance of computation of 
character widths in a multi-byte locale, which is now improved. I've 
also changed the memory allocation in the relevant code to use the heap 
instead of the stack, which should fix the issue with stack overflow 
Tobias experienced while testing.

The progress bar/printing would be more efficient if the line buffers in 
Rgui could keep already pre-processed \r(s), but that would require a 
somewhat bigger change, and hopefully it won't be needed.

Thanks a lot for the report and the nice small reproducible example.

Best
Tomas