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. :slight_smile:

9 Likes

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!

2 Likes

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

1 Like

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.

1 Like

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.

1 Like

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

1 Like

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.

1 Like

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/issue/RIDER-92424/JetBrains-Rider-Editor-3.0.20-package-Update-for-Unity-Causes-Rider-to-Slows-to-a-Crawl-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

1 Like

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

4 Likes

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 :slight_smile:

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