Bug New Rider Integration -- high cpu in editor until you close rider

Editor Version 2021.3.17f1 --- JetBrains Rider Editor -- Version 3.0.20

This morning I installed the new rider package from 04-05-23. Ever since then after I press play, the Editor goes to high cpu usage and stays there. My Unity editor will remain with high cpu and bad performance no matter what I do. I can press play and run editor builds over and over and it has very low FPS and my operating system shows that unity editor is using high cpu.

If I close rider, everything goes back to normal and things work fine.....

If I do open C# project again, one build will work fine and then I go back into the broken state.

I believe that Rider plugin [3.0.20] has a bug with editor [2021.3.17f1].

Does anybody else have this issue? Hopefully this helps someone else.

 

Thank god someone else is talking about this. I have the same issue. How do I downgrade a package? all the other threads where people ask get met with "why would you want to do that". I really can't have this today. Got a lot of work to do!

 

Go to package manager > + dropdown > "add package by name" > com.unity.ide.rider 3.0.18

 

I removed/uninstalled the package and then closed unity. Reopoened and re installed rider plugin and got lucky and it went back to 3.0.18.

 

Is it specific to OS or Unity version?

 

I am on Windows 11 with Unity Editor Version 2021.3.17f1

I could try other versions of Editor later this evening if that would help. Its pretty easy to reproduce as of right now and I heard from a couple other people that they also hit this issue. Luckily rolling back isnt too difficult.

 

Where do you see or how do you measure the Editor FPS?

 

Open the profiler and press record. With the Rider 3.0.20 extension installed you will see lots of busy and slow things. Lots of big yellows. After you revert back to Rider 3.0.18 this goes away and the profiler is nice and quiet.

Also with Rider 3.0.20 extension installed, if you open task manager in windows you will see that Editor is always using 1 cpu core at 100% when Rider is open. If you close Rider or roll back to the 3.0.18 extension the cpu is very minimal. On mac you could probably witness the same thing with htop.

 

I also had the same problem described above (update caused Unity performance to tank). Am on Unity 2022.2.5. Have changed back to 3.0.18 and everything is fine again

 

Same issue here Win11, Unity 2021.3.22f1, Rider Build #RD-222.4459.9

 

Same here. 2021.3.15f1, just loaded 3.0.20 and in profiler the EditorLoop is now 120ms per frame instead of 5ms. Unusable, so going back to 3.0.18.

 

https://youtrack.jetbrains.com/issue/RIDER-92424
Sorry for the inconvenience, I hope we will provide a fix shortly. Please follow the link to track the progress.

 

Same here. Unity 2021.3.18f1. Rider 3.0.20 is currently unusable.

 

Thank you, I am also experiencing this problem

 

I have a possible fix, which can be tried by one line change in the manifest.json, see in: https://youtrack.jetbrains.com/issu...-after-updating#focus=Comments-27-7264417.0-0
Just currently struggle with stable performance repro to verity that it really helps.

 

For the time being, it might be easier for you guys to change the manifest version from 3.0.20 to 3.0.18, seems to be fixed, and you probably dont need to be on the bleeding edge of this rider plugin any way

 

Btw, thanks @van800 for being in here and getting on it quickly

 

Same issue Unity 2021.3.23f1 and Rider 3.0.20, a total nightmare. Changed it to 3.0.18 in the manifest.json and back to being a dream

 

I too confirm that rolling back com.unity.ide.rider to 3.0.18 has improved performance. Using Unity 2021.3.23.
However, I use PlasticSCM integration with Rider as well which has terrible performance anyway. So it's a bit hard to tell at times.

 

Unity 2021.3.20f1
JetBrains Rider 2022.3.3 Build #RD-223.8836.53, built on March 20, 2023
Windows 10

Rolling back to 3.0.18 fixed it. I was getting 80.4ms CPU frametime with 3.0.20, it dropped down to 8ms

 

Confirming 3.0.21 fixes the problem. Thanks @van800!

 

Using Unity 2021.3.23f1

Edit 2: Upgrading to JetBrain Rider Editor 3.0.21 and Visual Studio Editor (Unity integration) 2.0.18 seems to solve the original issue.

I'm seeing another issue where selecting a script in the Editor so it is displayed in the Inspector Window causes an unexpected spike in CPU. This doesn't seem to be related, as it also occurs in Unity 2021.3.16f1 using Rider 3.0.16 and VSE 2.0.16.

 

I'm on version 3.0.24, but Rider has become completely unusable for me with both insane CPU usage as well as memory usage. It feels like this happens in a specific project though, which is also the largest project I've ever had in Unity, but I still feel it's a modest project relatively speaking, and there's no reason for things to be this bad.

I'm around 20% CPU usage for Rider when just idling with the Unity project and Rider open. I have no idea what's happening. There are no progress bars in either Unity or Rider. CPU usage can go up to 70-100%, and memory usage can go up to 20GB+, or that's when Rider warns me it's running out of memory and I realize it's using all available memory.

I'm on Win 10, i7-8700K cpu and 32GB ram, and the project is on the latest 2021 LTS version.

Context actions never show up, syntax highlighting stops working, solution wide analysis stops working and Rider just stops alerting me of errors etc. In other words the entire application stops working like an IDE and instead just behaves like the world's slowest notepad, but this also affects the Unity editor and not just Rider itself. Sometimes when I'm editing a scriptable object or whatnot inside Unity it can freeze for upwards of 20-30 seconds with intermittent popups showing progress bars about "Rider dispatch tasks" or something like that.

If I restart Rider then it "works" for a little bit in the files I already have open, and sometimes works for new files as well, but quickly becomes worse and worse until it's unusable again.

I've never encountered anything like this in Rider (or PHPStorm which I use for work) prior to this. I'm mentioning this here because this is the closest thing I've found to my issue while trying to Google and search through both these forums and the Jetbrains issue trackers for similar issues.

I will try and debug what I can to see if I can figure out what causes this. Firstly I guess I need to try some other projects I have to see if they've regressed or if they are still how I'm used to, and then I guess I need to start deleting stuff from this project to see if I can figure out what causes it.

 

Pretty sure this is the job/message that pops up in Unity and blocks me periodically even though I'm not even touching Rider:

Code (CSharp):

1. Jetbrains.Rider.Unity.Editor.MainthreadDispatcher.DispatchTasks

I've tried deleting large parts of my Unity project, but not really found anything that remedies the problem or gotten any idea as to what causes the problem, and I don't really know if it's this project or if it would happen in any project, because I'm not in the mood to work on any other project at the moment, especially not to just try and sit there and see if Rider works or not, because it can sometimes take a while before Rider starts acting up.

But I decided I would just try downgrading to version 3.0.18 of the package, since that was what you recommended prior to releasing version 3.0.21, which is the version you claimed fixed the problems introduced in 3.0.20.

I can say that I haven't had these problems after downgrading, so I assume there are some situations where these problems still aren't fixed. Like I said with version 3.0.24 Rider was completely unusable, and it made Unity unusable as well. In fact it often made my entire computer unusable due to using all my ram and CPU, but the most noticeable problem i had was that syntax highlighting completely stopped working until I restarted Rider, context actions would just load forever, code completion wouldn't work, or the "error analysis" would not work at all until I alt-tabbed back into Unity and then Unity would tell me I had errors in my code, and if I alt-tabbed back into Rider then Rider would highlight the same errors, or it would sometimes do that, but it would never highlight any new errors. I could create any obvious syntax error in the code and Rider would just ignore it completely until I alt-tabbed into Unity. I had to alt-tab back into Unity every time to try and see new errors in Rider. It was as if Rider's analysis wasn't running until I alt-tabbed into Unity, and it would only run when the sync with Unity was happening or something, but at the same time some invisible process or whatnot in Rider would be running amok and just using more and more CPU and ram.

I also tried changing all settings for Rider and the Unity Rider integration like turning off analysis, solution analysis, roslyn analyzers, various refresh settings in the Unity settings in Rider, and invalidating caches, re-importing all assets, deleting the library, deleting project files for Rider etc. etc., but nothing made a difference. The only thing that has worked for me is downgrading to version 3.0.18 of the package.

Edit: Ohh, and the most bizarre problem was that Rider would simply refuse to apply syntax highlighting for files I opened in Rider while I was in play mode. It would just show all the files as plain text white text, but immediately if I exited play mode it would apply syntax highlighting, if the above problems hadn't caused it to deteriorate to the point where syntax highlighting already wasn't working in general.

This problem is also fixed after I downgraded to 3.0.18.

 

I'm using Rider 2023.2.3, Unity 2022.3.9f1.
I was using version v3.0.26 of the integration package, and I was having lots of Play Mode performance issues while debugging (Attach to Unity Editor).

It seemed the more time Unity was running and the more times I used debugging in Rider, Play Mode would progressively get slower, making me restart Unity very frequently to be able to debug my project.

Following this thread's suggestions, I downgraded the integration package to v3.0.18.
After that, the "slow performance while debugging" issues didn't happen anymore.

 

It worked for me. Thank you!