PyCharm's Transition to Apple Silicon | Hacker News Reader

PyCharm's Transition to Apple Silicon

blog.jetbrains.com

66 pointsgamesbrainiac27 comments

Wow, these are heroic efforts that show a tremendous dedication to achieving acceptable performance and rendering.

Which is a surprise to me because I don’t really consider the jetbrain products to be “performant”. They run fine, sure, but take a long time to start up or open a project, and can get sluggish if left open for awhile.

It can take long on an old system, but that doesn't matter much [to me] when the IDE works fast throughout the day even when periodically opening and closing projects.

IntelliJ start up time is much better now. Take a look on IntelliJ CE (ported to Apple Silicon) vs VS Code (under Rosetta 2) https://www.youtube.com/watch?v=Erg0Dz0MXww Of course this is unfair comparison, but you can see that the start up isn't slow.

That copy of VS Code seems to be starting very slowly, even taking the emulation into account. Lots of extensions, maybe?

For reference, it starts in around 3 seconds on my 2013ish laptop. (actually, more like 2014 - Haswell i7)

That's indeed not a fair comparison. Mozilla reported up to 2x faster performance and 2.5x faster startup time on the M1 port.

JetBrains IDEs are quite heavy in my experience. I like their capabilities (pycharms at least), but they do come at a cost.

My MacBook Pro 2019 model is about to take off if I use both DataGrip and PyCharm at the same time.

To be fair, a stern glance is usually enough to get a 2019 MacBook hot enough to cook your breakfast

Jetbrain stuff has always been slow - until I got an AMD 5600 (ram at 3200). For whatever reason, this combo of chip and updates to their software maybe (I turn off a lot of the add ins) - I've stopped being annoyed at the speed. It's "fast enough".

I don’t disagree with you, their IDEs have been full featured but a little slow. Suggestion, if I may: remove all plugins unless you really need them.

That changes on Apple M1 Silicon. PyCharm and IntelliJ native are very fast, as is Apple’s XCode. Life is sweet.

> To this end, we began to investigate how we could handle this transition with grace. It soon turned out that we had to re-write a lot of the JIT system, a core component of the JVM itself, which was something we had little to no experience in.

Why couldn't they just merge the (presumable) upstream OpenJDK support into their fork?

You would think that Java is maybe not the right tool for the job, if you have to write your own Runtime first.

This was my main thought. Maybe all that effort expended on managing the runtime could be aggregated into a unified effort in a more cohesive (to your goals) language.

IntelliJ had been based on java for twenty years. It has worked well as a mainstream cross platform application that has been around before, and outlived, other approaches.

Moving to another language would surely be many more orders of magnitude than plugging in a new JIT?

Lets see how far they actually manage to go with Kotlin/Native, they seem to be trying to make Kotlin the new Delphi.

I don't have any hopes for it besides Android, which is working thanks Google gatekeeping Java updates and pushing Kotlin instead.

They didn't write the runtime, they just modified a (relatively) small piece of it. From the article:

> JetBrains forked the OpenJDK project in order to facilitate better control over how the IDEs looked on Macs a well as other HiDPI screens; JetBrains Runtime was born and we bundled it with our IDEs from 2014.

> There are many facets of the runtime, and we do not know every little crevice of it, rather we focus on the part of the code that handles the rendering of UI on screens.

Here's the problem: they selected Java many, many years ago back when Apple shipped Java as part of Mac OS X. I believe they're based on IntelliJ and presumably have added a considerable amount of their own code over the last 20 years. They certainly didn't know that the Oracle acquisition would lead to Apple removing a not unpopular feature due to legal risks.

With a large cross-platform codebase like that, Java is an understandable choice and at any point the cost of switching would be greater than the cost of fixing the current issue.

This isn't it's own runtime. It's a modified JDK and when you're one of the largest pieces of GUI software in Java, you're obviously going to have things you want to change in it.

They've created a huge platform. They're going to have needs that aren't met in a pre-packaged thing.

VSCode avoided using any frontend frameworks, does that mean they made a wrong engineering choice?

Not necessarily. It could be that even though they have to rewrite some of the runtime it's still the right tool for the job.

Ah, yes. The classic let's rewrite everything from first principles instead of using a proven, state-of-the-art runtime for which we just to reimplement font rendering.

> To hear the whole story, listen to the podcast

Is there a transcript somewhere?

So here's the same podcast on YouTube: https://youtu.be/OgzERBIemjw

If you're on a computer, click the three dots that are to the right of "Save" and then click "Open Transcript". These are auto-generated so the fidelity may not be there but it's one shortcut to reading the podcast.

So, uh, is there an M1 build available now? It’s not clear to me from this blog post or scanning the release notes for the past few releases. Last time I tried PyCharm, in November I believe, it wasn’t really useable through Rosetta so was waiting for the native JRE.

I did not know Jetbrains ships it own JVM. What engine they use?

They use a forked version of OpenJDK.

See https://confluence.jetbrains.com/display/JBR/JetBrains+Runti...

tl;dr: Article has little substance and instead points reader to a podcast.

Ugh.

Reply on news.ycombinator.com