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.
- 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.
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.
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
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.
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!
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.
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.
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.
Readit News
- 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.
Deleted Comment
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.
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
Deleted Comment
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.
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!
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.
That 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
Something in the lines of Wine, I guess.
Deleted Comment