The latest Preview (Version 1.2.1206) and the previous both use an enormous amount of CPU. It looks like RStudio uses around 30% CPU and the underlying QtWebEngineProcess uses around 50% CPU for EVERY instance of RStudio that is running.
When RStudio is started, this happens immediately and the laptop's fan starts working hard.
I couldn't find any reports on this, which is strange as this is a showstopper for using the program :-/
I'm using a MacBook Pro, 16GB RAM, macOS 10.14.1 Mojave.
The QtWebEngineProcess executable is primarily responsible for rendering things on-screen, so I would normally only expect something like this if e.g. you were using large HTML widgets within the IDE, for example.
Any other information you can provide will be helpful.
If you have Xcode installed, you could also try running the Instruments application and using the Time Profiler to figure out what the QtWebEngineProcess process is doing -- although that's a somewhat more advanced debugging tactic.
I've now did a bit of poor mans profiling on the problem.
It also occurs in an empty project. (I closed the project and rebooted RStudio)
It also occurs in a RStudio with only the (empty) History, (empty) Console, and (empty) Environment tabs open
When RStudio is visible, QtWebEngineProcess takes 16% to 23% CPU, RStudio 30% to 42% and, newly observation, WindowServer 35% to 49% CPU!
When RStudio is hidden in macOS, QtWebEngineProcess takes 18% to 21% CPU and RStudio takes 8% to 10%. (I didn't observe WindowServer)
When RStudio is not running, WindowServer takes from 8% to 12% CPU (with the same programs running as above).
I then switched to software rendering as you suggested, with had the following impact:
QtWebEngineProcess fell to between 8% and 18% CPU, while RStudio serve grew to between 42% and 62% CPU!. WindowServer also grew to between 36% and 51%.
So that switch made a difference, but not to the better.
I'll now have a look at using Instruments app to collect information.
Attached is a screenshot from Instruments Time Profiler focusing on the _platform_memmove$VARIANT$Haswell which seems to be the "thing" eating up the most CPU in the RStudio process.
Thanks! That profile basically indicates what I suspected; all the time is being spent within QPainter() which implies all the time is being spent drawing on the screen.
Can you think of anything else that could be related? Are you using the laptop's builtin display, or an external monitor? Have you adjusted the machine's display resolution?
You could also try clearing out the various caches used by RStudio:
When I, as a test this morning, switched to the default (TextMate) RStudio theme, all performance problems went away!
So the theme apparently introduces some code that RStudio can't handle. Maybe the part of the Christmas theme that's to blame is a CSS animation (see at the bottom of the above linked blog post).
So, on the one hand, my problem is not stemming from RStudio, but on the other hand, this might be something that theme developers should be made aware of?
Anyway, my problem is fixed, it's a year until next Christmas, and I'll stick with the provided themes for the time being
I would like to thank you for your swift and serious response!!
Sorry everyone for the confusion and time spent debugging this issue. It makes total sense. The theme adds an animation to the cursor to change colors. I had originally limited it to just the vim normal mode cursor but then a few people who didn't use vim asked for the animation on the regular cursor. Hence the constant screen drawing.
I'll add a disclaimer to the theme repo and instructions for disabling the animation.
It's rather surprising that this could expend so many CPU cycles in just rendering a small keyframe animation. This sounds very similar to this issue in the VSCode repository: https://github.com/Microsoft/vscode/issues/22900
We may get a fix for this when we next update Qt (hoping to upgrade to Qt 5.12.1 before the release of v1.2 of RStudio).
