Related, about latency: https://news.ycombinator.com/item?id=16001407

links to: https://danluu.com/input-lag/

Title: Computer latency: 1977-2017

IntelliJ is really bad about this sometimes. I get that their software does an incredible amount of really tough stuff behind the scenes (which is why I won't be switching any time soon), but God I wish they prioritized input responsiveness over everything else.

Haha, I love the “My IDE is so sluggish, it must be doing important stuff”. It really isn’t. IntelliJ is just horribly laggish. VSCode, an electron (!) app with 100 plugins isn’t even that slow.

Yes. Even if it were doing important stuff, this "important stuff" shouldn't be affecting typing. We have multicore machines now, there's no excuse anymore.

Imagine if it were the opposite, and moving the mouse or speaking into a microphone caused the compilation to fail in subtle ways. Well, background compilation/typechecking/whatever is messing with user interaction.

I'm not naive, I've actually built IntelliJ plugins. I know engineers that work on the product, and I have an extremely good idea what it's doing under the hood. A lot of it is important to me and doesn't exist in VSCode, though that's also a great product for some languages.

They actually did:

https://blog.jetbrains.com/idea/2015/08/experimental-zero-la...

There were big improvements over time. IntelliJ performance seems to vary a lot between people. For some (like me) it's great. Others complain of huge delays. Probably, the differences are OS related and/or project size or plugins related. There are so many different configs possible for an app like that.

Jetbrains really should just update the JDK they use.

With a slightly larger max memory setting than default and using at least G1 garbage collector (ZGC for even better results) they would get a buttery smooth editor, but it is configured quite badly by default.

Though sometimes they just have threading issues, which won’t be solved by above.

1000% agree. I am disappointed [1] with JetBrains' attitude to this problem. They seem to judge anyone who isn't using the JDK11-based JBR in 2020 as a difficult customer, and do not acknowledge latency/lagging problems on Linux. Mac users then reply to threads like this saying "works on my computer flawlessly, I don't know what you're talking about", until they confess to being Mac users.

I have tried JAOTC up until JDK16 with some IntelliJ products, but I think you are right in saying that the single most effective knob (or two) to twiddle in the default installation is to enable ZGC and increase the heap size.

Yes, I know JBR provide DCEVM builds (which need to be enabled by downloading the JDK and changing the "boot java" setting, ironically)

[1] and by that I mean "fuming"

Yeah, vm options tweaks still don't cut it for me on my projects, and I've optimized pretty hard. Threading is the killer, esp. when connecting to other processes it can get all tangled up.

When I was in school we had 286 computers with windows on them. Some of them had input lag of about 7 seconds in the text editor we were using. Think it was Word but not sure any more. But at least they didn't miss keyboard input, every key stroke came out, just with more or less delay. I did most of my text editing at home on my Atari where there was no delay at all.

Even Apple’s bootloader on Macs is dropping keypresses now!

Starting some time in 2020, the FileVault password dialog will drop characters whenever I’m typing quickly. And it never dropped characters before 2020 – even though I’ve had FileVault 2 on for many years.

And that’s at bootloader runtime, with not a single bit of the macOS kernel loaded yet!

No, forward. Because the delay is probably because all of the telemetry and tracking, that has to be activated and synced with the servers, before it can responds to your request. All that amazing technology, unthinkable 20 years ago.

So definitely forward to big brother Panopticon.

Yes.