The culprit is the JDK11-based JBR. I was ready to dump JetBrains tools due to their lagginess, but with some deviousness (which might not suit you), I now have them running slipperier than a wet fish, by using JDK15/16 and JAOTC.

Instructions are here: https://iam.georgecox.com/2021/11/24/making-jetbrains-ides-r...

(I am very keen to tell people who are in the same despair as I was about how slow JetBrains apps are out of the box -- hope it's not considered bad form to link to one's own blog post about it.)

I've tried this now on my 2019 Macbook pro, and my 2018 Thinkpad T480 running Linux. On Mac, I can't say I really noticed a difference. Also there were quite a few font rendering issues that were resolved with whatever patches Jetbrains has applied. On Linux, certain actions are definitely faster. For instance, Ctrl+Tab to either quickly tab switch or bring up the tab switcher menu was always instantaneous, where-as beforehand there was sometimes a pretty long delay.

I will try this now; thanks for that!

please email me if you have any corrections / suggestions for improvement for the instructions :-)

Please note that the JBR is a custom build that contains a number of important changes and fixes, and it's not recommended to replace this. For M1 support, it's much better to use an M1 compatible JVM and .NET runtime. Rider 2021.2 is an Intel build, because when it was released there was no M1 compatible .NET Runtime.

Rider 2021.3 has an M1 build, and makes a big difference. It's currently in preview (https://www.jetbrains.com/rider/nextversion/) but will be released in the next week or so.

Liberica offers an M1 JVM https://bell-sw.com/announcements/2021/03/12/Liberica-on-App...

I wonder if JetBrains has some incentive to keep Mac users happy at the expense of others, because there is no justification for the unacceptably bad performance of CLion, PyCharm, and IDEA with a version 11 JDK on Linux, given how much better it is on JDK 15/16.

I have never seen any indication that they have are going to address this, nor have they even acknowledged that it's a problem, nor that they intend to upgrade from JDK 11 to something more up-to-date. Still, they have 1 year and 10 months from now until the end of active support, so perhaps this might provoke them into action.

The fact that JBR even exists is a red flag. Should every vendor ship their own JVM?!

This YouTrack item

https://youtrack.jetbrains.com/issue/JBR-3729

tells that JetBrains have been working on a JDK17 version of JBR for 2022.1, which amazingly, is almost upon us. I am looking forward to seeing what it's like!

I was under the impression that the JBR is missing a number of important changes and fixes that have already been mainlined into OpenJdk.

Would love to see some examples of this please :-)

If you're not using the EAP build of Rider, you're running an Intel IDE on that M1 laptop (see: https://rider-support.jetbrains.com/hc/en-us/articles/440192... ).

Try the Rider EAP with .net 6 - I find native arm64 .net flies on my M1 mac mini and M1 Max 14" MBP.

That's strange. When I open a 1m+ LoC in Rider it takes around 2GB of RAM [1] but is still very workable. Ofcourse it is not extremely fast but I am always impressed this even works with all the code hints, indexed code and what not.

By the way, sometimes a corrupted cache can be a problem. You can fix this via File -> Invalidate Caches.

[1] AMD Ryzen 9 3900X, 32GB RAM, NVMe disk. Ubuntu.

I have 3 main development computers on which I use CLion. One is shared duty workstation/server with 20 cores and 512GB RAM another is main desktop desktop with 16 cores and 128GB RAM and 3rd is tiny small factor PC with 8 cores and 128GB RAM which I drag around to summer cottage etc.

CLion is very fast on either. I guess gobbles of RAM counts. I also have laptops with 32GB RAM each but did not try it on those as I no longer use laptops for development (no business need).

Still as my main development language for backend is C++ I mostly use Visual Studio. Especially since their preview version allows seamless development / debugging on remote Linux server. Hard to describe but it just fits me better, feels more "natural".

Just in case you haven't tried that yet, increase the IDE's memory heap size. That solved the problem of sluggishness for me.

Why hasn't Java added an option for automatic heap sizing for the desktop application use case (or any use case, for that matter)? Seems like a no-brainer thing to add, so I guess there are Reasons(tm).

It has. Modern JVMs can use as much memory as they "need" to, but for some reason JetBrains don't use this feature. I think after they upgrade to Java 17 they'll get it. But this has really killed their brand for a long time. 99% of the time people complain about their IDEs being slow it's because the app is GC thrashing and burning CPU rather than increase heap size.

I was under the impression that every gc still defaulted -Xmx to 25% of available memory.

It is configured by jetbrains (I guess to not use as much memory as Java would default to)

Have you waited for indexing to finish?

Which bits are slow?