change the boot JDK from the version 11 JBR JDK to version 15 of Azul Zulu.

This didn't really work for me. I already had Azul's Zulu v15 installed so figured I'd give this a try.

I pressed ⌘ ⇧ A and typed "Choose Boot" in Actions, picked "Choose Boot Java Runtime for the IDE", then selected Zulu 15 and restarted IntelliJ… then the outline of main window loaded with its menu, but none of its contents. It was all gray and none of the panels ever appeared. They eventually showed up after I resized the window but I'd consistently get in this state each time the IDE started.

Also, the fonts didn't appear to render correctly. It's hard to say exactly what's wrong with them but the letter spacing and subpixel rendering seemed to be different.

Is there anything else to do to make this work without having to resize the window each time?

Gah. I do apologise. I should have mentioned I am on Linux, where updating to Zulu 15 works like a charm. (Zooming font size in the editor with scroll wheel is ... well, try it before/after :-)) The JBR has some fixes specifically for font rendering among others, on Mac OS X.

Sorry for getting your hopes up. OTOH, Linux on the desktop is pretty good in 2021 :-) In this case, it certainly beats the Mac! :-P

Funny, I used to think myself knowledgeable for knowing what JVM knobs to twiddle out of the box. Now I see that the fact they need adjusting out of the box is a weakness of the platform itself.

Wow. I cannot wait to try this but how is azul different from openjdk in practical terms?

Shouldn’t the latest openjdk release with ZGC be a better option for low-latency?

It would be, were JetBrains IDEs currently compatible with the latest JDK, but they are not, so it's not quite as simple as that, unfortunately.

IDEA and CLion won't start with JDK 16 or later, so I'm using JDK 15 for those. All the other JetBrains IDEs work with JDK 16. In all cases, features using the JCEF [1] runtime library, which is bundled with the JBR [2], will not be available.

I'm using these options on Debian/unstable on all JetBrains IDEs, with both JDK 15 and JDK 16.

  -XX:+IgnoreUnrecognizedVMOptions
  -XX:+UnlockExperimentalVMOptions
  -XX:+UseZGC
  -XX:-UseG1GC
  -XX:C1CompileThreshold=100
  -XX:C2CompileThreshold=5000
  -Xms4G
  -Xmx4G
  -XX:ReservedCodeCacheSize=512m
  -XX:SoftRefLRUPolicyMSPerMB=50
  -XX:CICompilerCount=2
  --illegal-access=permit

Adding -XX:ReservedCodeCacheSize= and -XX:SoftRefLRUPolicyMSPerMB= made all the difference in keeping heap usage down. I have not yet experimented with different values for those parameters.

The option --illegal-access=permit is required on JDK 16, but this option was removed in JDK 17, and because of this (but probably not only this) I haven't yet been able to make any JetBrains IDE work with JDK 17.

In adjusting all of these settings, YMMV depending on your system. Good luck!

[1] https://github.com/JetBrains/jcef

[2] which is currently based on JDK 11

While there are continuous performance improvements, between 15-17 it is probably not visibly so, but thanks for the config!

Ah cool, will try this out. Thanks.

There must be something wrong because they are pretty much best in class in terms of input delay since they improved it a few years ago.

What is wrong is JetBrains shipping a custom build of a version 11 JDK in 2021. Not using the JBR is the quickest way to a responsive JetBrains IDE.

Do you have any basis for this "best in class" claim? Have you tried VSCode recently? I think you'll find that it is much lower latency.

A quick search on the JetBrains bug tracker https://youtrack.jetbrains.com/ suggests that people have had problems over many years across different platforms.

For example: https://youtrack.jetbrains.com/issues?q=linux%20editor%20unr...

>Do you have any basis for this "best in class" claim?

Take a look at these benchmarks https://pavelfatin.com/typing-with-pleasure/#linux

These "benchmarks" are from six years ago in 2015 (which is more than you say "a few years ago") by a JetBrains employee, shilling his own work at the company, on his own blog. [1] Given that six years has passed, those results are irrelevant to today's shipping versions.

Things have evidently got much worse since that study was made. Lately, the editor is plagued not only with delays in syntax highlighting, but also complete lock-ups (keyboard unresponsive in editor panes), requiring the IDE to be restarted.

I have been a paying customer of JetBrains since 2015 and have found the recent offerings to be so goopy and slow that I was ready to cancel and switch to VSCode [2] like everyone else at work. The only thing which stopped me doing so was switching the boot JDK from JBR JDK 11 to Azul Zulu 15 (though I suspect any 15 JDK will have had the same effect.) Cancelling your subscription is the best way to be heard.

Constantly growing and developing software systems collapse under their own weight eventually, and JetBrains' products are no exception.

[1] I find it weird and distasteful that an employee is advertising the company's products in this way.

[2] or emacs, which is wicked-fast with native-comp