Almost everything triggers "getting the action ready"
I've been having an issue with rider where now almost anything I do is prepended with a message that reads:
'<Some action': getting the action ready. Press Esc to cancel...
And it takes maybe 10+ seconds for this "action" to become ready. Commenting out lines (like above), pasting, cmd-clicking on arguments to take me to their definitions, sometimes just trying to add a new line shows this kind of thing. Is there any way to make this suck less?
Please sign in to leave a comment.
We are aware of such problem for F# and what solution and OS do you have? Thanks!
Rider 2017.1 EAP
Build #RS-171.4456.902, built on June 29, 2017
Rider EAP User
Expiration date: July 29, 2017
JRE: 1.8.0_112-release-736-b17 x86_64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Mac OS X 10.12.4
Using it with a C# Unity project.
Same issues here making Rider almost unusable at times. It seems if I close down Rider, force quit any mono-sgen processes, then reopen it runs a little better. But it shortly afterwards becomes super slow again always trying to become ready.
macOS 10.12.5
Unity 5.6.2f1
Rider 2017.1EAP
Build #RS-171.4456.902
JRE: 1.8.0_112-release-736-b17 x86_64
JVM: OpenJDK 64-bit server VM by JetBrains s.r.o
Same here, Unity 2017.1.0f3 (same issue on 5.6.2p2). C#
Rider 2017.1 EAP
Build #RS-171.4456.902, built on June 29, 2017
Rider EAP User
Expiration date: July 29, 2017
JRE: 1.8.0_112-release-736-b17 x86_64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Mac OS X 10.11.6
I noticed that it always happens after stopping a played game in the editor. My Macbook Pro is a bit old, and sometimes I have to wait 2+ minutes just for the "getting action ready" to finish... I'm also using the VIM plugin if it means anything.
Huge bummer. I was so enthusiastic about RIder, telling people how much it has improved my productivity and experience with Unity, but this issue has me looking into VS for Mac. It has pretty much halted Unity development on my old machine.
Please try Rider RC build and let us know if it was fixed.
Fixed it for me (or at least improved the preformance a lot), thanks!
This has been biting me hard in a dotnet core project using C#7 constructs heavily (ie a lot of expression bodies, using statics, etc...)
Rider 2017.1
Build #RD-171.4456.1432, built on July 13, 2017
Rider EAP User
Expiration date: August 12, 2017
JRE: 1.8.0_112-release-736-b17 x86_64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Mac OS X 10.12.5
---
.NET Command Line Tools (1.0.4)
Product Information:
Version: 1.0.4
Commit SHA-1 hash: af1e6684fd
Runtime Environment:
OS Name: Mac OS X
OS Version: 10.12
OS Platform: Darwin
RID: osx.10.12-x64
Base Path: /usr/local/share/dotnet/sdk/1.0.4
Come to think of it, this started after the last Java update. It may be coincidence. But it may be a clue.
the RC seemed to help a little with the delay. However, I now frequently have 2+ mono-sgen processes taking up most of my CPU usage. I can't work a day in Rider without this getting out of hand and having to restart.
I run into this frequently as well with a large solution. Even just hitting the ENTER key gives me the "'Rider action': getting the action ready" message. It completely prevents me from typing anything. I would rather have degraded behavior than not being able to type anything.
Not fixed for me as of latest RC (2017.1). Seems to be an issue directly related to project size- I haven't seen small projects I work on experience this, just the big one that I have to do for work, it's 7k .cs files.
It feels to me that I have made the process a little better (~%10) by adding .meta and .asset files to the Ignore Files list.
I disabled as many unnecessary plug-ins as I could, and then in the latest RC they all got turned on again, so I am going to try disabling them again and seeing if that does anything. I do not believe it does, but it's worth a shot.
I have two solutions that I work on every week.
The first one is rather large and doesn't seem to be affected by this issue.
The other one, is new and pretty small. It gets locked up very quickly. The only thing I can think of that sets this solution apart is an extensive use of https://github.com/louthy/language-ext. and static expressions. I really hope it isn't that library causing issues. I know IntelliJ Scala has a lot of problems with FP. That would be a bummer if this was the case in Rider.
My environment specs are above.
Just noting that with 2017.1.2 i am still seeing this issue. Its becoming pretty much unusable...
For me it shows itself when copying and pasting... and after then quick code changes (typed or pasted) rider gets progressively slow and slower...
Rider 2017.1.2
Build #RD-171.4456.3568, built on September 15, 2017
JRE: 1.8.0_112-release-736-b22 amd64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Windows 7 6.1
Also experiencing very slow response time (around 5 seconds) while attempting to paste code into a C# file with around 1500 lines
Rider 2017.1.1
Build #RD-171.4456.2813, built on August 22, 2017
You have a perpetual fallback license for this version
Subscription is active until September 10, 2018
JRE: 1.8.0_112-release-736-b22 amd64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Windows 7 6.1
Hi Everybody! Thank you for the feedback.
Can I kindly ask to get a Timeline snapshot for us? Unfortunately for now it can be done ONLY on Windows, but it is relatively easy.
In Rider call
1. Tools -> Backend Profiling -> Start Timeline
2. Reproduce perf problem
3. Tools -> Profiling:Stop
4. Share the file with us, some ways are mentioned here
5. Create a new issue in Rider issue tracker. In the issue, provide a short description of the performance problems you're experiencing, and specify the name of your snapshot.
6. Follow up here with a link to issue for faster processing.
Thanks in advance!
I only get this issue on my largest project which has 5348 files. This issue goes away after disabling "Solution-Wide Analysis" in the bottom right. Not ideal having to disable it but I'm guessing that's why it tends to be related to project size, as it's picking up tons of errors across hundreds of files.
@Jake your OS?
Do you mean that you are typing/refactoring while SWEA is analysing for the first time?
If your are on Windows, it may worth be taking a performance snapshot as I wrote above.
Thanks!
Sorry! Details copied from Rider below:
---
Rider 2017.2 EAP
Build #RD-171.4456.3271, built on September 4, 2017
Rider EAP User
Expiration date: October 4, 2017
JRE: 1.8.0_112-release-736-b22 amd64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Windows 10 10.0
---
It's only recently started doing it for me, I think since I updated to 2017.2. When I boot up it would start it's Solution-Wide Analysis and about 9 times out of 10, when I go to edit something (new line, actual code, pasting something, anything really), it would hang for about 5-10 seconds. Seems to be more likely to happen if I haven't typed anything for a minute or so. Disabling SWA has "fixed" the issue.
Annoyingly I can't seem to reproduce this anymore. I think this may be because I accidentally left the SWA running for about 10 minutes the other day, and I think it's found most of the errors (960 across 271 files). Is there a way to destroy the error cache so I can re-index them and try to successfully reproduce the issue?
@Jake By default it must be %localappdata%\JetBrains\Transient\ReSharperHost\v10\SolutionCaches for windows.
Hitting this big time as well for a while now even on the latest 2017.1.2, and it's driving me crazy.
Anything I can do to help? Using Rider 2017.1.2 on macOS with a .NET Core 2.0. It's mainly while editing razor views.
Robert, could you try the latest EAP and let me know if the problem persists? https://www.jetbrains.com/rider/eap/
Yep, EAP 3 (installed today) seems to work much better. Still just a slight delay, but probably < 1 second vs the previous multiple seconds. Thanks.
I have encountered this problem a lot while debugging. I give up waiting after a few minutes as Rider just does not respond when trying to navigate or respond to commands ("getting the action ready"), or the response is very slow (10-30 seconds). I've also noticed setting breakpoints can often be impossible while debugging, the lag can be unbearable between clicking a line to set a break point on and Rider acknowledging the break point has been set. These issues are not apparent when not debugging.
JetBrains Rider 2017.2.1
Build #RD-172.4144.1873, built on November 13, 2017
Subscription is active until September 10, 2018
JRE: 1.8.0_152-release-915-b11 amd64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Windows 7 6.1
Still an issue on MacOS
Rider 2017.2
Build #RD-172.4144.1459, built on October 11, 2017
JRE: 1.8.0_152-release-915-b11 x86_64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Mac OS X 10.12.6
I got suddenly this trouble today with Rider on the NHibernate.sln from https://github.com/nhibernate/nhibernate-core/tree/master/src. I was fiddling with some tests from its test project. SWA is disabled.
I was getting the message on deletes, pastes, new lines, ... It was unusable. Restarting it was not helping.
> By default it must be %localappdata%\JetBrains\Transient\ReSharperHost\v10\SolutionCaches for windows.
It was in v08 in my case, and just in case I have purged it. Thankfully it allowed me to get an usable Rider back.
JetBrains Rider 2017.2.1
Build #RD-172.4144.1873, built on November 12, 2017
JRE: 1.8.0_152-release-915-b11 amd64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Windows 10 10.0
Windows 10 is 1709
Last day of trial period here and this is one of my biggest bugbears.
One thing I note: This mostly happens to me after I hibernate (maybe suspend too?) my laptop. Once it's happening, only restarting Rider seems to fix.
Unity 2017.03.01 + C# + Vim plugin (similar to Andre above). I'm now trying 2018.1 but had same problem with 2017.3.1.
JetBrains Rider 2018.1 EAP
Build #RD-181.4035.533, built on March 17, 2018
Rider EAP User
Expiration date: April 16, 2018
JRE: 1.8.0_152-release-1136-b16 amd64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Windows 10 10.0
I've the same problem just now (2017.3.1), however there is a promissing suspect: eager code analysis running into unintended loop while writing. Briefly, I've a situation writing a call with 2 overloads where first more general overload ends in regres in infinitum and there it crunches and I have to comment it out, invalidate caches and restart...
I found a possible cause. Having incorrectly applied rules in NetLimiter 4.0.36.0 is able to cause the issue - presumably by throttling connections between Rider and the Resharper host. Hope it helps someone else.
I still have this issue on the Mac version with C#. Restarting Rider will cause it to go away for a little bit, but once it comes back, Rider is pretty much unusable as any keystroke or action will cause the message and the pause.
JetBrains Rider 2018.1.4
Build #RD-181.5550.7, built on July 31, 2018
JRE: 1.8.0_152-release-1136-b39 x86_64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
macOS 10.13.6
It disappeared for a long time for me on Windows (through beta updates). It came back a couple of updates ago.
I also notice that when it happens, the JetBrains Toolbox shows odd behaviour, specifically while it shows its right-click context menu, it won't show the list of installed apps!? I have to restart the Toolbox to to get back to Rider. Every day. Or more than once if I hibernate my laptop which is what seems to cause it for me.
p.s. (EDIT) for those who remember my post above, yes I since bought full suite :)