"Save as" dialog very slow in RStudio Preview on Ubuntu


#1

When selecting “Save As…” from the “File” menu, the dialog opens immediately but it takes up to seconds until the window is filled with contents. Typing a file name also feels very sluggish. This does not occur in 1.0.153, only in 1.1.379 (and also the previously released preview version). I’m on Ubuntu 17.04.

Can you replicate? Happy to look further into it.


#2

I have the same problem here! Sometimes it completely blocks RStudio and I need to reopen…


#3

I’m not able to reproduce this on my Ubuntu 17.04 machine. Can you provide any other details? A short screencast of the issue would be useful as well.


#4

List of installed packages: https://gist.github.com/krlmlr/5bb56116deeb822dac15d04a9b3d3fde

Screencast: https://www.dropbox.com/s/3a8i0b2hml09ilz/rstudio-save-as.ogv?dl=0 . Shows the same behavior three times, different behavior in a fresh RStudio session at about 01:10


#5

Thanks for providing the video. What desktop environment are you using in this case?

Do you see the same issue if you launch RStudio to use the GNOME theme? You can do this (assuming the pre-requisite packages are installed) with something like:

QT_QPA_PLATFORMTHEME=gtk2 rstudio

Also, it wasn’t quite clear based on the video, but are you using a high DPI monitor?

The last thing I’d ask you to try, if you have the time – can you try attaching a sampling profiler to RStudio, and trying to see what it’s stuck doing during that time? You might have a preferred profiler already, but one way to do this would be something like:

valgrind --tool=callgrind rstudio

Then, attempt to open the ‘Save File’ dialog a few times, to get the profiler capturing that execution. You could then share the captured profile with us, so we can see what was going on here.


#6

Thanks. I’m running Ubuntu GNOME with more or less default settings.

The QT_QPA_ env var didn’t help, but then I’m not sure if I have all prereqs installed. How can I tell?

The main monitor is a high-DPI monitor, the video shows the secondary monitor. The behavior is the same if only the primary monitor is active.

Profiler run, hitting “Save as” twice: https://www.dropbox.com/s/yoyvtcobwlvevqi/callgrind.out.14877.gz?dl=0. I zero-d the counters with callgrind_control -z after startup has completed but before running “Save as”, and aborted with Ctrl+C.


#7

We’ve still not been able to reproduce this, but we’ve had several reports. I’ve opened an issue on Github to track it: