Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

IntelliJ IDEA 2021.1

blog.jetbrains.com

Post reply on HN
Print view View original

61–70 of 77 posts

Re: IntelliJ IDEA 2021.1

#61

Post by LeonM »

dijit wrote: post #53
LeonM wrote: post #46

Earlier quoted context omitted.

Not an expert on the subject, but AFAIK Jetbrains runs their own Java VM by default. To run intellij on Wayland you do need _JAVA_AWT_WM_NONREPARENTING=1 in your env. It works, but has some quirks as I wrote above.

Sorry, that's not true. This just makes it "work", but it's still being rendered in Xwayland. Here's how you can test: Run intellij; `pkill Xwayland` or, try running intellij on a machine which does not have xwayland installed at all. The thing is: wayland does _not_ have scaling issues, those are inherently X11 problems. The issue which is tracking this: https://youtrack.jetbrains.com/issue/JBR-3206 I also just ran…

Looks like you are right, I didn't realize that Xwayland was still used in the background.

Re: IntelliJ IDEA 2021.1

#62

Post by lmilcin »

darksaints wrote: post #17
imeron wrote: post #5

Started off as very slow on a not-terribly large project > cache cleanup > does not even start without trashing the .idea folder anymore > still slooow. Command + space takes forever (=seconds) to show the context menu. IntelliJ feels like a proper IDE now :).

The problem is that Intellij is written in Java, using the hotspot JVM, which is JIT compiled. But IDEs, especially fully featured IDEs, are a terrible type of workload for JIT compilation. They're full of branches, which can easily cause recompilations, and the breadth of features mean that there is never really a spot hot enough to stay compiled outside of the editor itself. I really wish AOT compilation was taken…

If that was "the" problem, why would past versions of IDEA be fast?

Java and JVM are very fast. I know, because I used to do cutting edge algorithmic trading in C with premise that Java is slow and then I was asked to rewrite it to Java with the result being only about 10-30% slower. In this case we are talking receiving messages from network, performing complex processing and sending responses (on another connection) within 5-10 microseconds.

And that was a decade ago, my understanding Java only got better in the meantime, but I am working on more mundane backend/reactive systems and don't require really low latency.

Re: IntelliJ IDEA 2021.1

#63

Post by pjmlp »

coldtea wrote: post #59
pjmlp wrote: post #22

Earlier quoted context omitted.

Hotspot can cache generated binary code across runs since Java 11, but people keep using Java 8....

IntelliJ comes (optionally, but by default) with it's own packaged JRE/JDK/Java version iirc, so that wouldn't be an issue...

Apparently they couldn't be bothered to provide an AppCDS archive in modern JVM to go alongside InteliJ.

Re: IntelliJ IDEA 2021.1

#64

Post by KronisLV »

Tuna-Fish wrote: post #24
KronisLV wrote: post #18

Earlier quoted context omitted.

> It is a memory hog This is different from my experience, when working on Java projects with a few thousand source files and about 1 million SLoC. Eclipse - had some problems with the autocomplete being slow to open, IDE was overall unresponsive and used around 2 GB of RAM NetBeans - the cache folder filled up weirdly quickly (though that was NetBeans 8.2 not the new Apache NetBeans), but the IDE worked fine with ar…

> JetBrains - project was slow to open (+while indexing), but the IDE performs okay with 0.5 - 1 GB of RAM usage (though more needed when running/debugging) Just to be specific: Is this your experience just running the IDE at default settings, or did you increase the JVM heap size for it and had no effect? If you run it at default settings, the memory footprint will stay My experience on this is that it's a great ide…

I bumped the limit up to 2 GB, which is where i've left it for IntelliJ IDEA.

When the IDE is mostly idle (with 10-20 opened source files), it generally uses around 0.5 GB of RAM.

When i'm writing code, using autocomplete, reading documentation, running Maven actions, using the suggestions functionality (basically IntelliSense + some plugins), using refactoring functionality etc., then the memory usage can be bumped up to 1 GB.

When the code is running, the memory usage can get closer to the 2 GB limit, when using debugger functionality, recompiling classes on the fly and so on.

Personally, i haven't bumped the limit up higher, because i still need the memory for the actual Java processes of the services that i launch, since under normal circumstances i need at least 16 GB of RAM for all of the services to even run properly (but that may as well be a project related issue, since scheduled processes and a number of other optional things run locally, nor are all of them configured with Xmx and other parameters), though that's less relevant to the actual IDE performance (since i have swap turned off and it doesn't have an impact).

Re: IntelliJ IDEA 2021.1

#65

Post by KronisLV »

xxs wrote: post #39
KronisLV wrote: post #18

Earlier quoted context omitted.

> It is a memory hog This is different from my experience, when working on Java projects with a few thousand source files and about 1 million SLoC. Eclipse - had some problems with the autocomplete being slow to open, IDE was overall unresponsive and used around 2 GB of RAM NetBeans - the cache folder filled up weirdly quickly (though that was NetBeans 8.2 not the new Apache NetBeans), but the IDE worked fine with ar…

If you know anything about java you'd know that it has max heap settings that are a command line option. Pretty much all java command line options, GC ergonomics incl are there. I have been using eclipse with an increased heap (and over tuned) since 2006 - modify eclipse.ini

This would matter if one of them had the limit that's much smaller than the others, which would lead to aggressive GC, which wasn't the case.

When working on the same project of a known size and using similar IDE functionality, different IDEs still had noticeably different performance characteristics (i implore you to try the same, especially with the same Xms and Xmx values set).

That simply leads me to believe that each IDE implements things differently, for example:

  - JetBrains have separate IDEs for separate languages (IntelliJ IDEA for Java, Rider for .NET, PhpStorm for PHP etc.)
  - NetBeans allows lazily loading support for different languages/frameworks/tools
  - Eclipse is generally viewed as a bunch of interconnected libraries/frameworks (JDT for Java, PDT for PHP etc.)
That's just one example of the architectural differences (which may impact which functionality is loaded when and how efficiently the memory is used), though it stands to reason that it's perfectly normal to observe them to act differently from one another, even in controlled circumstances, like the above.

Re: IntelliJ IDEA 2021.1

#66

Post by selivanovp »

lumost wrote: post #12
victor106 wrote: post #8

Earlier quoted context omitted.

It works great if you give it enough memory. It is a memory hog but its the best IDE I've ever used.

They really need to update the default memory footprint. The 750MB default isn't enough for any projects these days and they don't exactly make it obvious how to update it to 2-4GB.

No need as you’ll get a warning on low memory if you’re on a large project, and IDE will advice you to increase heap size (just click provided option) and you can manually choose how much memory to provide.

So it’s fine that default is relatively low.

Re: IntelliJ IDEA 2021.1

#67

Post by darksaints »

lmilcin wrote: post #62
darksaints wrote: post #17

Earlier quoted context omitted.

The problem is that Intellij is written in Java, using the hotspot JVM, which is JIT compiled. But IDEs, especially fully featured IDEs, are a terrible type of workload for JIT compilation. They're full of branches, which can easily cause recompilations, and the breadth of features mean that there is never really a spot hot enough to stay compiled outside of the editor itself. I really wish AOT compilation was taken…

If that was "the" problem, why would past versions of IDEA be fast? Java and JVM are very fast. I know, because I used to do cutting edge algorithmic trading in C with premise that Java is slow and then I was asked to rewrite it to Java with the result being only about 10-30% slower. In this case we are talking receiving messages from network, performing complex processing and sending responses (on another connection…

I never once said Java was slow. I was saying that JIT compiling is a bad fit for an IDE. The workloads present in an IDE cause lots of problems for JIT compilers. And those problems actually can be exacerbated by an evolving code base with lots of new features.

Re: IntelliJ IDEA 2021.1

#68

Post by darksaints »

coldtea wrote: post #58
krzyk wrote: post #26

Earlier quoted context omitted.

AOT can't take into consideration runtime, which might result in less efficient code compilation vs JIT. So it is apples vs oranges. One is faster here the other there. GC might be an issue, but for me IDEA feels fast and the added benefit of code navigation vs e.g. vim is worth it.

> AOT can't take into consideration runtime, which might result in less efficient code compilation vs JIT. That has for decades been a "in the future we'll have flying-cars" style promise for 99% of workloads... Sure, JIT can theoritically optimize based on runtime hints. But most of the time, for any practical use, it's slower than AOT.

JITs have been extremely successful for dynamically typed languages, but that has always been a low hanging fruit for optimization.

Once you have a static type system, the JIT doesn't bring you much over ordinary AOT compilation, and no benefit over PGO...while losing out on global optimizations that aren't feasible in a JIT.

Re: IntelliJ IDEA 2021.1

#69

Post by ytjohn »

zibzab wrote: post #4

The remove editor stuff looks very interesting! While you don't normally do any complicated editing on remote machines, the ability to run the backend on wsl2 or docker allows me to have different environments for different projects. This was added to Visual studio code last year and worked very well.

When a job change forced me onto a Windows environment, having that remote option in vscode is probably the biggest factor that let me keep that job. This was back on WSL1, which was horrible, so I ended up running a linux VM to get full docker and Linux support. I tried pycharm through vcxsrv, but it was just a bit off. But with the ssh plugin to vscode, it was incredibly slick.

WSL2 would have the same advantages - a linux vm running under hyper-v. I see PyCharm 2021.1 has the same WSL connectivity as IntelliJ, so I will have to try this out. Would love if they added an ssh option.

Re: IntelliJ IDEA 2021.1

#70

Post by lmilcin »

darksaints wrote: post #67
lmilcin wrote: post #62

Earlier quoted context omitted.

If that was "the" problem, why would past versions of IDEA be fast? Java and JVM are very fast. I know, because I used to do cutting edge algorithmic trading in C with premise that Java is slow and then I was asked to rewrite it to Java with the result being only about 10-30% slower. In this case we are talking receiving messages from network, performing complex processing and sending responses (on another connection…

I never once said Java was slow. I was saying that JIT compiling is a bad fit for an IDE. The workloads present in an IDE cause lots of problems for JIT compilers. And those problems actually can be exacerbated by an evolving code base with lots of new features.

> The workloads present in an IDE cause lots of problems for JIT compilers

This would suggest the JIT is a problem. But that is not true, the "workload problem" really means "bloat".

Any software is written for the machine it runs on and Java programs are written for JVM. No machine is perfect and writing performant software requires that you understand peculiarities of the architecture you are working on. If you ignore it it is not the problem of the platform, the problem is you.

Now, the trouble with Java software is what I call "OOP bloat", which is basically overloading the runtime with overheads of abstractions.

What is acceptable level of overhead will depend on how much you value your time vs performance of application so it is not categorically declare it is bad. That assuming the overhead is accomplishing something else (like making the code simpler, easier to develop/maintain).

Post reply on HN