IntelliJ Idea 2020.3.1 Is Out with Apple Silicon Support | Hacker News Reader

IntelliJ Idea 2020.3.1 Is Out with Apple Silicon Support

blog.jetbrains.com

225 pointsjmnicolas120 comments

I know it's not the main purpose of this post, but does anyone here have any singularly powerful steps they took to improve performance on a JetBrains IDE after picking the low hanging fruit of the Java heap size and disabling unused plugins? Especially when running the debugger? (Using PyCharm specifically)

A big one is to make sure you’re excluding directories that you don’t want indexed.

One thing I've noticed is that CLion seems to at least partially index things in the directory tree even if they're in your excluded set. Seems like a bug, but I gave up fighting with it, and I gave up trying to get the Chromium source tree to be workable in CLion at all, even on a 48-core Xeon with 256GB of RAM (not joking). But my coworker had some success by creating a second directory which was just symlinks for the code he was interested in, and opening CLion on that. Painful, but worked, kinda.

This is a huge one. If PyCharm is indexing one of your PyPi or NPM caches, the memory footprint dwarfs your active code by orders of magnitude.

Thanks. I had done this a while ago and rechecked it. Found a couple of new ones, but nothing major. I'm thinking of abandoning PyCharm altogether. Was really using it mostly for it's great debugger, since I had such a good experience with IDEA, but there's only so much slowness, hanging, and system resource hogging I'll put up with. Maybe it has to do to some degree with the type inference demands of Python. Gonna give Eclipse with PyDev a whirl this weekend.

Two bandaids that have helped me:

- On a large file, or in a slow project, put the Inspection Level down a notch. (You can get to it from the Actions keyboard shortcut.) You can nudge it back up, including for whatever big file -- when needed.

- Install the plug-in "Automatic Power Saver," which does that automatically upon loss of focus. (Well, maybe down two notches?) I do notice the switch/transition sometimes but it makes my overall session so much smoother (mainly because browser and IDE aren't being slower than their combined slowness)

p.s. I've been dealing with JetBrains IDEs' slowness for 5+ years, have done the same workarounds you mentioned etc. I always have another fast editor set up, lately VS Code. For quick edits etc. I had a coworker who would use their JetBrains IDE only for the last stretch of their branch or ticket -- to get the inspections and other tools. I supposed I picked this up from them.

Make sure you're using the latest JB SDK. https://intellij-support.jetbrains.com/hc/en-us/articles/206...

Yes, actually.

Two things to change to (likely) boost your JVM+IntelliJ performance:

1. Use the new ZGC garbage collector.

-XX:+UnlockExperimentalVMOptions -XX:+UseZGC

2. If you're using ZGC, it is fucking imperative you do not use compressed pointers. It will totally hose your system and you'll see unbelievable RAM thrashing (800mb to 16gb and back again within a few hundred milliseconds in one smallish project I have [and thats on a 5950x]). That is to say, after enabling ZGC, ensure you do NOT have the following configuration line:

-XX:+UseCompressedOops

I've been using ZGC for a few days and I have to say it's been fucking great. Before I'd get really long hangs due to GC; or eventually the editor would grind to a halt (after like 8 hours of usage). I've had the editor open for at least 48 hours now and it's just as fast as it was when I originally opened it.

Somewhat unfortunately, I just tried that (on Mac, latest CLion) and it didn't work. I edited the `vmoptions` file to remove `-XX:+UseConcMarkSweepGC` and `-XX:+UseCompressedOops`, added `-XX:+UnlockExperimentalVMOptions` and `-XX:+UseZGC`, and the IDE failed to start until I restored the original file content.

Increasing min RAM from VMOptions.

Well, two Java features of modern toolchains (previously only available in 3rd party commercial JDKs) would be to take advantage of native images and JIT caches between runs.

Then there are the possible uses of G1 and Shenandoah.

This just in the context of OpenJDK, other implementations have their own JIT, AOT and GC variations to choose from.

So running on latest versions of a JDK already helps.

Me personally, I am happier using Eclipse and Netbeans anyway.

Doesn’t IntelliJ use its own bundled JRE? If that’s the case, it won’t matter which JRE you have installed.

JRE are gone as of Java 9 actually, replaced by application custom images produced via jlink.

You can still get JRE, but they aren't as official as they used to be until Java 8.

And in any case, customization flags for which GC to use, or JIT caches, are part of any Java runtime implementation.

yeah, stop using python

Seems like Apple's timing on the M1 releases is spot on. Wide availability of the M1 based systems now is enabling developers to port software quickly. By the time the Pro machines are launched, it's likely most of the pro tools will be migrated across.

The fact that they actually gave a preview hardware to developers months ago kinda helped.

Absolutely. All around, it's been a well organized migration. I'd originally thought they would launch one of their faster CPUs right off the bat, but in retrospect this makes more sense. If they'd pushed out the 16" MacBook Pro, the expectations that Pro software would work out the gate would be a lot higher.

One of the things that I wish IntelliJ had was some way of doing some "real world" benchmarks.

It'd be great to know exactly what sort of speed improvements this might bring (or if it's really faster at all).

It _seems_ like IJ could be scripted using the plugin system to do things like:

- Load and apply formatting to a 1 MB source file.

- Index an entire project.

- Run a regex find/replace on a code base.

- Load 50 code files and time how long it takes for each to be ready to display.

Mac meta-scripting / macros / virtual keyboard/mouse scripting exists.

This would be difficult to make meaningful because projects vary by orders of magnitude in performance-relevant metrics, as does user behavior.

IntelliJ has an enormous number of features and people use their own subset of them. Not to mention things like plugins and other options for customization. It's a huge space.

But as far as making perf improvements to IJ itself, that actually would be meaningful: it would allow them to say "commit eeffaa takes 2m16.555ms" to perform the steps outlined by nvahalik, but "commit aabbff takes 2m01.222ms" and thus it's getting better for that metric

I wholeheartedly agree there will always be very weird setups on very weird source, but if they can make the 80/20 run faster, hopefully a rising tide will lift all boats kind of thing

It's not just "very weird setups." Totally normal setups differ greatly.

One example of variation is that the users might be writing code using different languages. The parser and static analysis for a project written in Go will be very different than a project written in Java. All the language-specific stuff is different code that has different performance characteristics.

As an analogy, it's sort of like testing browser performance for loading an "average" web page, when each web site has different performance, depending on how it was written. Load times for Hacker News aren't all that relevant for Gmail or the New York Times.

Yes, you can make a benchmark and optimize it, but you might not even be running the same code that real users are running, due to plugins.

Great idea!

I wonder what they changed? You would think that Java code would simply be faster out of the gate with a native JVM. Perhaps there's more natively compiled Kotlin code than I expected?

Although I kind of like IDEA and (particularly) PyCharm in terms of functionality (and dark mode, which they've had for a while), I quit using them because I didn't like the sluggish/underwater feel.

I think they use a slightly custom JVM that modified slightly from the standard one. This release must include such changes, I guess.

Officially there is no upstream release of Java that supports macOS on ARM64 due to the lack of W^X support. You have to manually backport the patches or build from master.

> I quit using them because I didn't like the sluggish/underwater feel.

Thanks for posting this -- I thought it was just me.

Curious about the speed diff - could some give notes on that?

Speed difference of M1 (native) vs Intel (I have an i7 Mac mini and M1 Mac mini): It is snappier and more responsive than ever before, but that's to be expected since the M1 single-core performance is so much better. It feels like a breath of fresh air!

Speed difference of Rosetta vs native: It was unusable for me on Rosetta. Super delayed responses for everything, and used a lot of memory. I temporarily switched to the Exploration version of VS Code while I waited for Jetbrains to update. :)

I also can't agree more! IntelliJ IDEs have been my go-to since giving it a try during the End of the World sale in 2013. The IDEs have a robust feature set that makes development a pure joy. That joy has subsided in recent years with performance on Mac Intel. There are several open YouTrack issues regarding this: looking to move to Metal; 4k external monitor performance issues; scrolling.

This release makes the IDE so incredibly fast! Indexing dependencies happens magnitudes faster than Intel version. With many of my projects I have used in it, if you tried to hold your breath from the time you started the IDE until it was ready to begin editing you'd have passed out unconscious. Now, the IDE is ready to begin work quicker than you could recover from a heavy sneeze! It IS a breath of fresh air. Searching all files is about instantaneous; navigating file trees is snappy and responsive; opening Settings modals happens quickly. What a joy!

That joy has subsided in recent years with performance on Mac Intel. [...] This release makes the IDE so incredibly fast! Indexing dependencies happens magnitudes faster than Intel version.

These must be macOS issues or problems with the limited thermal envelopes ofIntel Macs. I have noticed the same issue with my Intel MacBooks, it's slow and the fans spin loudly.

I never had that issue on Linux with a Ryzen CPU (3700X) though. The JetBrains IDEs are lightning-fast, including indexing. My only gripe is that they do not have native Wayland support and as a result the IDEs are blurry with GNOME fractional scaling.

There are some issues about this in their bug tracker, but the JetBrains personnel either do not seem to understand how the Linux graphics stack works (and come with non-solutions) or say that it is low on their priority list.

I have a ToolBox subscription (among other reasons because IntelliJ is still the best Java IDE). But with the progress that Visual Studio Code makes with e.g. Rust support and JetBrains' slow progress on many issues, I will probably switch to VS Code at some point.

Just to echo that going to Ryzen made a world of difference. I had a big jump from some intel APU part to the 5600x - makes jetbrains much more pleasant.

I'm not planning on switching back over, but others in the family are and Jetbrains packages were always clearly "slow" so speed of the chips actually made a difference to my eyes.

Rendering on 4K displays in MacOS has been broken for five years!

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

I dropped my everything sub over this and then moved on to vscode once its vim plugin was of equal caliber.

I've been using IntelliJ for over 5 years on 4K displays and never experienced this.

Same here. Would be interested to hear what the issue was when they finally resolve that ticket.

That's weird, I run IntelliJ perfectly fine on a retina MBP with two 1440p displys (so I get to see both HiDPI and rgegular DPI working on the same machine at the same time), and my 4K Dell XPS laptop.

I've had the same problem on the regular MBP Retina display. I have heard before that it may be related to scaling; I scale my display to have the smallest text/largest available real-estate possible. But I gave up on JetBrains before testing that theory.

I run mine on a 2015 13" MBP against an external 1680x1050 display. Changing the scaling on the display helps a little, but it is still laggy like I'm on an intercontinental SSH session.

Most of the features that you point out are IO bound. E.g. indexing dependencies, navigating/ searching files. Are you sure that the speed up is because of the new IDE release and not because of a new laptop?

I'm sure it is a bit of both. I was using the Intel version of the IDE until the release today. It took a long time on my Intel MBP and it also took a long time on my M1 with Intel. The ARM version of the IDE is substantially faster, as it should be. I do realize this is an unscientific anecdotal account of the situation so YMMV.

> IO bound. E.g. indexing dependencies

That's enough HN for me today and I just started...

I have a 2015 MacBook for work and use jet brains. It’s quite snappy and responsive. Id expect it to be better on newer hardware but am left wondering why performance degraded so much for people?

It didn't. Many people just want it to be instantaneous they way something like Vim or Sublime is, and it just isn't.

But it's in no way any worse on modern machines that what you see in your 2015 MacBook (I have several Macs and can attest). People complain despite getting better performance than what you get on later Macs/PCs.

The other case is too many / too slow plugins. Not all are made equal. But as far as the core functionality, there has been no regression all the years I'm using it.

I use IntelliJ on a 2015 Macbook pro and an equivalently old Dell Latitude running Ubuntu 20.04. The mac has only an i5 dual core processor with 8GB RAM while the Dell has an i7 quad core processor with 16 GB RAM. I hardly find any performance difference with IntelliJ on both the machines.

I too use it on an older (2014) mbp, and it is fine for Rubymine.

I highly suspect the performance problems some people experience are due to plugins. When I was doing some Elixir/Phoenix work, the Elixir plugin made it unusable sometimes. Clearly that plugin had some serious issues which would appear at times. I have not had the same performance problems in Rubymine or in vanilla IDEA.

I've had sluggishness on a 2019 MBP with totally vanilla Webstorm, no third-party plugins. It was usable, but bad enough to turn me off and send me back to VSCode.

My work laptop is a 2018 or 19 i5 13" MBP with an Intel GPU. It sometimes feels slower than my old MBP (i7 with Nvidia 680 or somesuch GPU). I doubt the CPU difference is the issue, but perhaps there's enough GPU difference that can cause IDEA to be slower on machines without a dedicated GPU.

Or who knows; could be something about the projects - number or sizes of files, language used and references between files, etc.

It's much faster than on my 2017 MBP. It's hard to measure UI like things though.

Using the Azul jvm builds, my java test suites on the MBA M1 run in 1/2 the time compared to the 2017 MBP.

I'm excited to see what the real pro machines can do when they come out.

Does this mean Pycharm et al. will also have support?

Thought I saw an update yesterday on PyCharm and DataGrip for this specific thing.

And maybe Clion too.

Probably in the next version.

Yay. They are near to officially demanding more RAM.

Do Some apps not run on m1? I’ve never heard this.

I believe they’re just referring to the fact it’s native and it’s no longer being utilizing Rosetta2. Since it’s bundled with its own JRE/JDK, and other components, perhaps they just have it all compiled for M1. I was supposed to have my new MacBook Pro a couple weeks ago, but my company ordered an Intel when I specifically told them NOT to. I need to test these things out before I get them to my developers as well. Plus yes, I want a new toy. I’m waiting for a mini (for myself) to show up at my house, but I waited a long time, and that won’t be here until the end of the month. Grrrr. I really want to test Logic Pro with it!

> perhaps they just have it all compiled for M1

That won't work because of the missing W^X support in upstream releases. You need to backport patches.

well here you go:

apps are natively compiled for instruction sets eg: x86, x64, ARM64 etc.

M1 has an new instruction set. so Apps targeting (x64, x86) need to compile specially to run natively on M1 chip.

currently there are few apps which are native as the chip is new. Apple has provided rosetta emulator, which will emulate x86 apps to run on M1

strange, everyone talked rosetta emulator in every single benchmark.

NOTE: the above is my current understanding. it may be slightly or grossly incorrect in some areas

Anyone know what rewriting for M1 actually entails? Guessing maybe you just recompile all your libraries for M1 and fix any errors and warnings that crop up.

Having said that some consideration to keep in mind:

- audio code needs to be optimized for real time thread constrains. Many optimizations usually made by vectorizing rather than threading that would've lead to locks and synchronization not always possible for real-time processing. So not all SIMD code can be compiled just by changing a flag.

- machine specific code. While rare. Some companies still got such code for various reasons. And needs more complex transition.

- Not all companies were able to obtain DTK. We for example, got our first M1 machine 3 weeks ago.

- Backward support. While we'd like to have universal builds, musicians use their systems for years. We still support 10.7. With Big Sur Apple seems to break SHA1 signs making builds from Big Sur work reliably only on 10.11 or newer. (The first release to support SHA256 codesigns) https://news.ycombinator.com/user?id=rock_artist

Basically, just recompile for the M1. For the rare apps that have some assembly or cpu-specific intrinsics (e.g. for vectorization in math-heavy code), you'll need to port those to ARM64 as well, but that should be very rare.

Atomics can be a pain point as well. The strong memory model of x86 tolerates sloppy use of atomics so bugs can easily fly under the radar, until the code is re-compiled for a weaker memory model like ARMs and suddenly you have a nightmare web of race conditions to deal with.

IDEA contains a JRE which has a JIT compiler. This is of course entirely cpu-specific, so had to be completely redone. OFC, ARM JITs for java already existed so they just had to ship to one of those.

Porting PyPy is harder than just re-running the compiler, because PyPy contains a few big architecture-dependent "details", like the JIT compiler and the foreign function interfaces (CFFI and ctypes). More details found at: https://news.ycombinator.com/item?id=25591695

Any "hot spots" that have been optimised by writing assembler has to be re-written. Same applies to any dependencies with similar optimisations.

Well except that they can benefit from many years of Linux (and Windows) on AArch64, as a result of which OpenJDK is already ready and optimized AArch64.

As far I understand the Rosetta2 is not an emulator, but a layer that translate x86/x64 binary code to M1 binary code, it does not emulate a x86 machine in the system.

Something in the lines of Wine, I guess.

There is also an emulator layer. It's used as a fallback when the much faster ahead-of-time binary translator can't work. The emulator is generally not a good experience -- if you have to use it, you really want to go native asap.

Examples where it is required is any kind of self-modifying code, such as JITs and the like. Since IDEA is a java application that ships with it's own JRE, the aot translator can only translate the JRE parts and when the execution first jumps to freshly written memory the system bails to the emulator. Since the emulator is an order of magnitude (probably more...) slower than native, and the entire IDE runs on JIT, this is very bad.

It includes a full emulator, there's no other way to run code generated at runtime which it can do.

You're right.

As mentioned in the release notes IntelliJ ran under Rosetta 2 previously (Apples x86 to ARM emulation layer) but this new release adds native ARM (Apple Silicon) support.

I have a PyInstaller-compiled Qt .app that crashes on startup. Weird, because Intel Python in Intel PyCharm is actually working just fine.

Docker for example (might have been fixed now)

Docker works you just can’t virtualize x86 images

The tech preview[1] works and you can run x86 images (though you get a warning from the CLI).

[1] https://www.docker.com/blog/download-and-try-the-tech-previe...

Google Drive Streaming specifically will not work on Apple Silicon yet.

I would assume it's because they depend on the JVM.

X86 JVM runs fine under Rosetta2. Will will be faster now. Looking forward to it!

I am really really waiting for new macbook pro 16" with M1X chipset to launch!

Does this also count for other Jetbrains IDEs (as they have a common core)?

Here is what is available: https://i.imgur.com/hA1Pq0Z.png

IntelliJ, WebStorm, DataGrip, GoLand, RubyMine

Which JVM are they using?

They are using a light fork with most patches improving font rendering/anti-aliasing https://github.com/JetBrains/jdk8u https://github.com/JetBrains/JetBrainsRuntime

I used Intellij years ago on Linux, nice to know that they improved font rendering. It was really ugly back then.

I'm surprised the JVM itself would be concerned with such things? That seems like it would be a standard library fork

How much of IntelliJ is native code, JVM or Python code (or maybe something else)?

Almost all JVM, mix of Java and Kotlin. https://github.com/JetBrains/intellij-community

Does Apple ship an optimized JVM or is this under Rosetta?

JetBrains ships a custom JVM that their IDEs run on.

https://confluence.jetbrains.com/display/IDEADEV/JetBrains+R...

My mac did not come with a working native JDK, I had to install the Azul one built for M1.

What changes are needed to make Aarch64 support? Java is write it once run it everywhere, the code is generated at runtime and can fully exploit the latest arch specific extensions like AVX 512 automatically

Edit: is it because they ship a custom jdk and that the jdk is in C++?

I've run IntelliJ on aarch64 using my system jdk11 instead of the bundled one. I ran into issues with two native binaries that come bundled with it:

1. An inotify library for detecting file changes. In this case, IntelliJ detected that it didn't have a binary for my architecture and just let me know it would be slower. Not a big deal.

2. The async profiler[0]. While available for other architectures, only x86_64 binaries are bundled with IntelliJ. And unfortunately, it didn't detect this either; it just quietly failed to work.

Hopefully with this patch they've also fixed these issues on linux-aarch64.

0. https://github.com/jvm-profiling-tools/async-profiler

Even if it was 100% written in Java (like GraalVM and RikesVM), the JIT, AOT and GC need to be updated for Apple Silicon.

Apple Silicon (as you know) is AArch64. Given that OpenJDK already had AArch64 support (e.g. through years of Linux AArch64 support, but also OpenJDK for iOS) and macOS support, I would bet that it is mostly a matter of making the build infrastructure aware of the macOS + AArch64 combo. It's not like JIT, AOT, etc. need full new ports to Apple Silicon (in fact, the Azul builds were available pretty much immediately after the release of M1).

Not quite, it is almost AArch64, plus some additional goodies.

Azul uses their own implementation anyway, so whatever they do isn't a reflection of what OpenJDK supports right now.

Not quite, it is almost AArch64, plus some additional goodies.

It is AArch64, it's not like it's an incompatible ISA. The fact that it has extra platform features does not slow down the initial port.

I am also not sure what 'additional goodies' you are referring to, for which specs are available (you can currently only use the neural engine through Apple's framework)? The fact that it's the first CPU (AFAIK) that is ARMv8.6-A?

These goodies,

https://github.com/AdoptOpenJDK/openjdk-build/issues/1922

OpenJDK does support AAarch64 for JDK 8 onwards[0]. Available as part of Ubuntu 18.04 as well[1]. I've used it quite a bit, and for the most part it's slightly faster than it was on x86_64 (though how much of this is due to JIT differences as opposed to core performance I can't say).

0. https://hg.openjdk.java.net/aarch64-port/jdk8/

1. https://packages.ubuntu.com/bionic/arm64/openjdk-8-jdk/filel...

Except Apple Silicon is more than just AAarch64, hence Azul and Microsoft contributions.

https://www.infoq.com/news/2020/09/microsoft-windows-mac-arm...

That does not refute the point. M1 uses the AArch64 ISA, so for the initial port, the existing AArch64 support in OpenJDK can just be used.

Sure, they can make optimizations now or in the future for ARMv8.6-A or the Neural Engine (if they are ok with going through Apple's framework). But M1 could pretty much use the existing AArch64 code from day 1 and have good performance.

(See benchmarks that float around the net where OpenJDK on AWS Graviton is competitive with Intel CPUs.)

It is more than just the CPU.

https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/...

I should have made it clearer; the section of the comment to which I was replying was:

> ...so whatever they do isn't a reflection of what OpenJDK supports right now.

I just wanted to point out that OpenJDK itself does support the architecture, and has for some time.

Yes, they ship custom JDK (BTW. This is now expected of all Java apps - jlink and lack of JRE since version 11) so they need to ship JDK that is Aarch64

That’s exciting, I was just looking at the status of this yesterday.

Why is it called AArch64 and not Arm64?

Arm's own naming nomenclature. It's a trademark thing.

Because AppleArch64 is not the same as Arm64.

Apple originally called it ARM64; the AArch64 name comes from ARM and was used by everybody else so Apple adopted it.

https://www.phoronix.com/scan.php?page=news_item&px=MTY5ODk

Reply on news.ycombinator.com