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 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!
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.
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.
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.
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.
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.
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
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
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.
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.
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!
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.
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.
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?
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 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.
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.
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++?
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
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).
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).
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.)
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?
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.
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)
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.
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.
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.
- 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.
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.
It's important to compare it to a solution with similar capabilities, like VS Code + some LSP server and you will see that both memory and cpu consumption-wise it's almost the same weight class nowadays...
Object-oriented programming is a tired gimmick, and JVM tooling and its bloat is so two decades ago. We have better tools now, we should be using them!
If you are utilizing the JVM via Clojure, the situation is not that bad. A lot of Clojure's and Java stdlib's features are now available pre-compiled with GraalVM as a native executable via https://github.com/babashka/babashka, which provides you with instant process start
So the Java ecosystem is kinda living its renaissance now :)
Yeah, all of this is no longer true for java. I've worked on many jvm projects not long ago, I've never had one that would work just out of the box. You might be able to download the repo and open it, but be prepared to get reamed for a week trying to get intellij, maven/gradle, and all the other dependencies to talk to one another.
The whole point of java was to make large, dependable, and easily refactorable projects that were also highly portable. Yet at least half of the time when working with these project it's wrestling with esoteric configurations. Java cares so little about the developer experience that I don't think they even take it into consideration, unlike Go or Rust. Should I even mention the God-awful debugging? Ugh.
As for intellij, the only real use it gave me was making me hate my mouse. It's practically a running joke at this point that the amount of mouse clicks in intellij is directly proportional to your devness, haha. It's fitting because java makes even the worst, laziest developers look employable because it takes 800 lines to make a REST api, so it looks like they're doing a ton of work when in reality they're just cutting and pasting.
With the rise of containerization and languages like Go and Rust, pretty much any benefit or edge that java had is now basically gone. Java is a maintenance only language at this point and any company doing green-field dev work in java is effectively a boomer company. As long as I live I won't touch another JDBC template or Maven xml. Fuck that whole ecosystem.
Java is indeed feels like Assembly, compared to other JVM languages, but in large part because of its typed and object oriented nature. I have a very different experience with the JVM ecosystem when using Clojure.
It definitely doesn't "require 800 lines to talk to a REST API" if you use this HTTP server/client lib, written in pure Clojure: https://http-kit.github.io
I'm primarily developing Clojure software, using IntelliJ and I mostly use the keyboard for it.
Cmd-E for recent file or Tool window (Clojure Deps) switching.
This is what I use the most.
Cmd-Shift-A for the Action Menu, which I use for Window Split Down/Right or Run tests and a couple of REPL commands, like copy the last result to the clipboard or open it in a browser. Opt-Tab to switch between splits. I don't switch between tabs, because I limited the max number of tabs to 1.
Cmd-, - Preferences
Cmd-; - Project structure
Cmd-Shift-O - Open files
Cmd-Shift-F - Search Files recursively in the whole project
Cmd-1 to focus and turn the Project file structure on and off, Cmd-Shift-Left/Right to resize it, Shift-Esc to close it (or any other tool window).
Cmd-9 for version control. Cmd-Shift-]/[ for moving between tabs. Ctrl-V for VCS operations menu, like (1 or just Enter) commit, (7) branch, (8) push.
Reassigned F12 to Cmd-2 to focus/show/hide the Terminal. Esc to switch the focus back to the Editors (which is buggy for years now and registers the Esc key in the terminal, but it's just a slight annoyance)
Cmd-Opt-R to run Clojure REPLs. Ctrl-Enter to eval top-level form or Ctrl-Shift-Enter to eval sexp before caret in the REPL. Cmd-Shift-J/K to barf/slurp, Cmd-' to raise and Cmd-(/[/{ to wrap sexp. Cmd-Shift-Up/Down to move an expression backward/forward within its containing expression. Cmd-/ to comment. Alt-Up/Down for Expand/Shrink selection by syntactical units. Refactoring with Ctrl-T.
Everything else is just opt/shift/ctrl/cmd + cursor keys, space, tab, shift-tab, enter or fuzzy search by simply typing the name of something in a popup list, dialog box or tool window.
These shortcuts cover ~80% of my time using IntelliJ, but I use another 10-20 keybindings, like folding an file structure navigation, which cover 95% of the use-cases.
It's also important to add that my CapsLock acts as both Ctrl and Esc and I'm using the SpaceFn layout via Karabiner Elements (as implemented by the jeebak complex modification). This makes a tremendous difference in convenience when using anything really from the keyboard primarily.
Well, all I can say is that this does not map onto my experience at all. Indeed I was about to mention the debugger as one of the main feature advantages :) The claim that you need 800 lines to make a rest api is simply not true, unless you are talking about java6, raw servlet development, which noone does nowadays. With Spring, it's 4 lines counted (of course, not counting Spring itself and less than 10 lines of global configuration). Intellij covers a good 80% of the keybindings I need out of the box, and I customized a 10% on top of it. I need to reach the mouse for operation that I might need to do once a day or less. Otherwise, everything related to coding, refactoring, testing, coverage, configuration checks, running and debugging is completely covered. And I have not been touching xml or raw jdbc templates for literally years. I'm sorry you had a less than optimal experience, to develop experience in a platform sometimes is less about using it and more about dodging bullets :)
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.
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.
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.
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.
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.
124 comments
[ 3.0 ms ] story [ 189 ms ] threadThat won't work because of the missing W^X support in upstream releases. You need to backport patches.
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
- 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
Something in the lines of Wine, I guess.
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.
[1] https://www.docker.com/blog/download-and-try-the-tech-previe...
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. :)
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's enough HN for me today and I just started...
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 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.
Or who knows; could be something about the projects - number or sizes of files, language used and references between files, etc.
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.
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.
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.
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.
Edit: is it because they ship a custom jdk and that the jdk is in C++?
Azul uses their own implementation anyway, so whatever they do isn't a reflection of what OpenJDK supports right now.
0. https://hg.openjdk.java.net/aarch64-port/jdk8/
1. https://packages.ubuntu.com/bionic/arm64/openjdk-8-jdk/filel...
https://www.infoq.com/news/2020/09/microsoft-windows-mac-arm...
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.)
https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/...
> ...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.
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?
https://github.com/AdoptOpenJDK/openjdk-build/issues/1922
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
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.
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.
- 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.
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.
https://confluence.jetbrains.com/display/IDEADEV/JetBrains+R...
Java needs to die a fiery death.
i hope they won't use M1 as an excuse for new baseline when comparing performance
it still is super slow for what it does
I disagree - it's much faster than any IDE of equal strength that I've come across.
Care to elaborate why?
So the Java ecosystem is kinda living its renaissance now :)
But overall I very much share your sentiment.
Also worth noting that if you really want to slim a JVM runtime down, from a typical ~300MB size to ~50MB, it's not very complicated using `jlink`: https://medium.com/de-bijenkorf-techblog/creating-the-smalle...
It's still 50 times more than what I consider sane, but still... ;)
Yeah, all of this is no longer true for java. I've worked on many jvm projects not long ago, I've never had one that would work just out of the box. You might be able to download the repo and open it, but be prepared to get reamed for a week trying to get intellij, maven/gradle, and all the other dependencies to talk to one another.
The whole point of java was to make large, dependable, and easily refactorable projects that were also highly portable. Yet at least half of the time when working with these project it's wrestling with esoteric configurations. Java cares so little about the developer experience that I don't think they even take it into consideration, unlike Go or Rust. Should I even mention the God-awful debugging? Ugh.
As for intellij, the only real use it gave me was making me hate my mouse. It's practically a running joke at this point that the amount of mouse clicks in intellij is directly proportional to your devness, haha. It's fitting because java makes even the worst, laziest developers look employable because it takes 800 lines to make a REST api, so it looks like they're doing a ton of work when in reality they're just cutting and pasting.
With the rise of containerization and languages like Go and Rust, pretty much any benefit or edge that java had is now basically gone. Java is a maintenance only language at this point and any company doing green-field dev work in java is effectively a boomer company. As long as I live I won't touch another JDBC template or Maven xml. Fuck that whole ecosystem.
It definitely doesn't "require 800 lines to talk to a REST API" if you use this HTTP server/client lib, written in pure Clojure: https://http-kit.github.io
I'm primarily developing Clojure software, using IntelliJ and I mostly use the keyboard for it.
Cmd-E for recent file or Tool window (Clojure Deps) switching. This is what I use the most.
Cmd-Shift-A for the Action Menu, which I use for Window Split Down/Right or Run tests and a couple of REPL commands, like copy the last result to the clipboard or open it in a browser. Opt-Tab to switch between splits. I don't switch between tabs, because I limited the max number of tabs to 1.
Cmd-, - Preferences
Cmd-; - Project structure
Cmd-Shift-O - Open files
Cmd-Shift-F - Search Files recursively in the whole project
Cmd-1 to focus and turn the Project file structure on and off, Cmd-Shift-Left/Right to resize it, Shift-Esc to close it (or any other tool window).
Cmd-9 for version control. Cmd-Shift-]/[ for moving between tabs. Ctrl-V for VCS operations menu, like (1 or just Enter) commit, (7) branch, (8) push.
Reassigned F12 to Cmd-2 to focus/show/hide the Terminal. Esc to switch the focus back to the Editors (which is buggy for years now and registers the Esc key in the terminal, but it's just a slight annoyance)
Cmd-Opt-R to run Clojure REPLs. Ctrl-Enter to eval top-level form or Ctrl-Shift-Enter to eval sexp before caret in the REPL. Cmd-Shift-J/K to barf/slurp, Cmd-' to raise and Cmd-(/[/{ to wrap sexp. Cmd-Shift-Up/Down to move an expression backward/forward within its containing expression. Cmd-/ to comment. Alt-Up/Down for Expand/Shrink selection by syntactical units. Refactoring with Ctrl-T.
Everything else is just opt/shift/ctrl/cmd + cursor keys, space, tab, shift-tab, enter or fuzzy search by simply typing the name of something in a popup list, dialog box or tool window.
These shortcuts cover ~80% of my time using IntelliJ, but I use another 10-20 keybindings, like folding an file structure navigation, which cover 95% of the use-cases.
It's also important to add that my CapsLock acts as both Ctrl and Esc and I'm using the SpaceFn layout via Karabiner Elements (as implemented by the jeebak complex modification). This makes a tremendous difference in convenience when using anything really from the keyboard primarily.
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.
Thanks for posting this -- I thought it was just me.
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.
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.
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
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.
IntelliJ, WebStorm, DataGrip, GoLand, RubyMine
https://www.phoronix.com/scan.php?page=news_item&px=MTY5ODk