JBR very slow compared to OpenJDK

[lamka02sk]

Hi, I was reporting this issue already in YouTrack, and mentioning this multiple times, but nobody cares :(
The JBR on Linux is extremely slow compared to OpenJDK. About twice as slow. The problem is, OpenJDK doesn't really work well with 2021.2 IDEs, so I had to downgrade and I will be probably stuck on versions 2021.1 forever since this issue with JBR has not been adressed for over a year now.
I will gladly sent you any information or do any testing to help you finally fix this issue.
For benchmark, I locked my CPU to static frequency (1.4GHz on all cores) and did this small benchmark:
OpenJDK 11 - PHPStorm startup with medium project: 23 seconds (stopped when code editor and file tree loaded)
JBR bundled with 2021.1 - PHPStorm startup of the same project: 45 seconds

All of my devices have this problem and all are running Linux (Kubuntu 21.04, Ubuntu 20.04 LTS KDE Neon and Ubuntu 18.04 LTS KDE Neon)

Thank you for your help

System info:

Operating System: Kubuntu 21.04
KDE Plasma Version: 5.22.4
KDE Frameworks Version: 5.85.0
Qt Version: 5.15.2
Kernel Version: 5.14.2 (64-bit)
Graphics Platform: X11
Processors: 8 × AMD Ryzen 7 4700U with Radeon Graphics
Memory: 14.5 GiB of RAM
Graphics Processor: AMD RENOIR

[bulenkov]

@lamka02sk Thank you for the report. We will start an investigation asap and will let you know about the progress. Could you please go to PhpStorm main menu Help -> About and click on Copy button, and then share the result?

[lamka02sk]

Thank you for your response. Here is the output you requested with removed sensitive info. When I am on my main PC later today, I will post also config from PHPStorm 2021.2 here.

PhpStorm 2021.1.4
Build #PS-211.7628.25, built on June 30, 2021
Runtime version: 11.0.12+7-post-Debian-2deb10u1 amd64
VM: OpenJDK 64-Bit Server VM by Debian
Linux 5.14.2
GC: G1 Young Generation, G1 Old Generation
Memory: 1600M
Cores: 8
Registry: ide.windowSystem.vScrollChars=10, idea.true.smooth.scrolling.high.precision=false, idea.true.smooth.scrolling.pixel.perfect=false, run.processes.with.pty=TRUE, ide.windowSystem.hScrollChars=10, ide.new.color.picker=false, ide.balloon.shadow.size=0, eslint.additional.file.extensions=svelte
Non-Bundled Plugins: com.intellij.javafx (1.0.3), org.intellij.plugins.postcss (211.6693.64), com.jetbrains.ChooseRuntime (1.2), com.mallowigi (36.0), ideanginx9 (0.1.9), in.bulma.snippet.intellij (6.2.3), lermitage.intellij.iconviewer (1.10.0.193), org.toml.lang (0.2.153.4056-211), ua.in.dej.myEmmet (1.2.5), com.shen.plugin.element (2.0), dev.blachut.svelte.lang (0.20.0), com.dmarcotte.handlebars (211.6693.44), com.chrisrm.idea.MaterialThemeUI (6.7.2), de.espend.idea.laravel (0.15.4), de.espend.idea.php.annotation (8.0.0), lt.martynassateika.idea.codeigniter (0.5.2), fr.adrienbrault.idea.symfony2plugin (0.23.211), ru.adelf.idea.dotenv (2021.2)
Current Desktop: KDE

with default runtime enabled:

Runtime version: 11.0.11+9-b1341.60 amd64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.

[lamka02sk]

Sending info from PHPStorm 2021.2.2:

PhpStorm 2021.2.2
Build #PS-212.5284.49, built on September 16, 2021
Runtime version: 11.0.11+9-Ubuntu-0ubuntu2.20.04 amd64
VM: OpenJDK 64-Bit Server VM by Ubuntu
Linux 5.11.0-34-generic
GC: G1 Young Generation, G1 Old Generation
Memory: 2200M
Cores: 16
Registry: run.processes.with.pty=TRUE, ide.new.color.picker=false, ide.balloon.shadow.size=0
Non-Bundled Plugins: com.vecheslav.darculaDarkerTheme (1.2.0), org.toml.lang (0.2.155.4114-212), net.seesharpsoft.intellij.plugins.csv (2.17.1), com.intellij.javafx (1.0.3), com.intellij.ideolog (203.0.27.0), ideanginx9 (0.1.9), org.intellij.plugins.hcl (0.7.14), com.jetbrains.ChooseRuntime (1.2), com.mallowigi (41.1.0), com.jetbrains.plugins.jade (212.5080.8), com.dmarcotte.handlebars (212.4746.57), ru.adelf.idea.dotenv (2021.3.0.212), de.espend.idea.laravel (0.15.4), de.espend.idea.php.annotation (8.0.0)
Current Desktop: KDE

with default runtime enabled:

Runtime version: 11.0.12+7-b1504.28 amd64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.

[LifeIsStrange]

@bulenkov any update?

[avu]

@lamka02sk we're looking into this issue.

[LifeIsStrange]

Unrelated: It'd be nice if you benchmarked ZGC and shenandoah vs G1 on JDK 17, it might improve Intellij perceived performance
See also: https://kstefanj.github.io/2021/11/24/gc-progress-8-17.html

[Ristovski]

@LifeIsStrange I wouldn't recommend ZGC - while it does have excellent GC performance, it uses way too much memory. On my 16GB laptop, it almost always causes excessive swapping due to memory exhaustion.

[Kademlia]

I can confirm this finding. My use case is remote-developing game server (Minecraft) on Ubuntu 20.04.3 LTS (GNU/Linux 5.4.0-89-generic x86_64) from Windows 10 64bit with Eclipse (2021-12 RC1) as IDE in my case.

Using OpenJDK (build 17+35-Ubuntu-120.04) there are some performance-reductions compared to no debugging.
Using jbrsdk_dcevm-17_0_1-windows-x64-b164.8 & jbrsdk_dcevm-17_0_1-linux-x64-b164.8 the performance suffers a lot more. Making it not possible to run the server without lags anymore (Ryzen 5950x on both client and server).

The performance is 'ok' before any code-change was done. It drops specifically after a code-change.
(Additionally disconnecting from the server seems to revert the changes or something? It at least results in a crash for me)

@Ristovski Depends a lot on the use case. For memory-agressive programs like a Minecraft-Server ZGC is amazing. Before I was running G1 specifically with flags (like G1HeapWastePercent) to allow higher wasted memory percent as it reduces CPU-Load from GC.

[skybber]

As far as dcevm-17, are you running it with -XX:+UseG1GC ? Anyway, dcevm discards the entire code cache after redefinition, so that's the reason why you are observing the performance drops, it should improve after several seconds.

[Kademlia]

Hey, I tried it again (params: -XX:+AllowEnhancedClassRedefinition -Xmx6G -XX:+UseG1GC -XX:+UnlockExperimentalVMOptions --enable-preview -server -agentlib:jdwp [...])

After a code-change the performance was maybe at 5-10% from before. This unfortunately did not change significantly after repeating the tasks for about 5-10 Minutes.

[osialr]

This is a workaround I found for slowdowns: OPENJDK_FFS_USE_FC=no OPENJDK_FFS_LOG_FC=yes ./clion.sh

I have a similar issue with UI freezing with JBR that isn't present with openjdk. Using perf, the font-config lib was consuming a whole cpu core for multiple seconds whenever I changed font size along with UI stuttering when viewing new code or menus.

After disabling the font-config code path in sun.font.FreetypeFontScaler.getGlyphImageNative, the UI slowdowns go away and match UI responsiveness of openjdk. This worked for both clion and intellij. The only tradeoff I've seen so far is that I had to install the jetbrains-mono font locally. My screen is 1080p so I don't need high-DPI scaling that the JBR fork provides.

System Info

Kubuntu 20.04.3
CLion 2021.3.2
Build #CL-213.6461.75, built on December 28, 2021
Runtime version: 11.0.13+7-b1751.21 amd64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
Linux 5.4.0-94-generic
GC: G1 Young Generation, G1 Old Generation
Memory: 8192M
Cores: 8
Registry: processes.with.pty=TRUE clang.parameter.info=true
Non-Bundled Plugins: org.toml.lang (213.5744.224) IdeaVIM (1.9.3) org.rust.lang (0.4.163.4378-213)
Current Desktop: KDE

Technical Details

This what's in the console log when I change font size or open a new UI element such as menu or settings with envvar OPENJDK_FFS_LOG_FC=yes.

FC_LOG:   FC_HINTING(1) FC_HINT_SLIGHT JDK_AA_LCD_HRGB FC_ANTIALIAS(1) FC_AUTOHINT(0) FC_RGBA_RGB FC_LCD_DEFAULT
FC_LOG: Noto Sans /usr/share/fonts/truetype/noto/NotoSans-Regular.ttf  size=9.062500
FC_LOG:   FC_HINTING(1) FC_HINT_SLIGHT JDK_AA_OFF FC_ANTIALIAS(1) FC_AUTOHINT(0) FC_LCD_DEFAULT
FC_LOG: Noto Sans /usr/share/fonts/truetype/noto/NotoSans-Regular.ttf  size=9.062500
FC_LOG:   FC_HINTING(1) FC_HINT_SLIGHT JDK_AA_OFF FC_ANTIALIAS(1) FC_AUTOHINT(0) FC_LCD_DEFAULT
FC_LOG: Noto Sans /usr/share/fonts/truetype/noto/NotoSans-Regular.ttf  size=9.062500
FC_LOG:   FC_HINTING(1) FC_HINT_SLIGHT JDK_AA_LCD_HRGB FC_ANTIALIAS(1) FC_AUTOHINT(0) FC_RGBA_RGB FC_LCD_DEFAULT
[continues to repeat]

Snippet from async profile.

          ns  percent  samples  top
  ----------  -------  -------  ---
 22915318329   57.57%        0  /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.12.0
  7315137963   18.38%        0  __strchr_avx2
   200055947    0.50%        0  FcConfigSubstituteWithPat
   190099661    0.48%        0  SymbolTable::lookup_dynamic(int, char const*, int, unsigned int)

To me, it seems that openjdk code path has a caching mechanism for fonts that JBR does not.

[avu]

Thanks for the findings, we'll look into it

[jebeaudet]

Any update on this? Using OPENJDK_FFS_USE_FC messes up completly the monospaced font I'm using in the editor, I've played around a bit to get it the same without success.

Thanks!

[fatihdogmus]

i can confirm that this problem exists with JBR 17 with Intellij 2020.3 on Windows 10. I tried using temurin and JBR 17 and the difference is night and day.

[romanstingler]

I don't want to offend anyone, but I don't get it why creating yet another JAVA package when it was already stated in more than 20 YouTrack issues that OpenJDK works better than the bundled one (fonts are rendered properly on OpenJDK, performance....).

[LifeIsStrange]

yeah if they have improvements they should upstream them, this issue show the danger of forking, they don't have enough human resources allocated/bug report feedback to properly assume the performances risks of said fork.

[avu]

@fatihdogmus Could you provide some more details about your problems with JBR17 on Windows. What JBR17 builds did you use? What is your configuration?

[avu]

@osialr could you try the latest products - I see no difference in startup between OpenJDK and JBR on my linux desktop (AMD® Ryzen 9 5950x 16-core processor × 32, AMD® Radeon rx 6800 xt, RAM 62.7 GiB)

[osialr]

@avu Yes still having stuttering/UI freezes in 2022.1. It's most noticeable when changing font size in editor, opening menus, or scrolling. I have been documenting the problem in IDEA-287246. It has a video included visible to the jetbrains-team.

I have tracked it down to apt install kubuntu-desktop libreoffice on ubuntu 20.04. It puts more rules in /etc/fonts/conf.d and adds over 2000 fonts to fc-list. That adds a significant overhead to the libfontconfig API in use. (PR #121 attempts to address it by caching the API calls). I reproduced the slowdown on two laptops, in docker, and in VMs.

These are example steps for docker. Host OS is Ubuntu 20.04.4 LTS and Docker version 20.10.12, build e91ed5707e.

In this part, UI runs fast:

1. docker run -it -u root -e DISPLAY=${DISPLAY} --net=host --name=jbr-ISSUE84 rycus86/intellij-idea:2022.1
2. Checkout a maven project like https://github.com/jenkins-docs/simple-java-maven-app.git
3. Turn on mouse-wheel to changes font size (Settings->Editor->General->Mouse Control)
4. Open pom.xml and a java file then CTRL-scroll a bunch to change font size. Should be fast.
5. fc-list | wc -l reports 6 fonts

Now install libreoffice and kubuntu-desktop. This takes about 20 minutes to run.
6. apt-get update && DEBIAN_FRONTEND=noninteractive apt-get install -y libreoffice kubuntu-desktop
7. quit intellij
8. relauch intellij with docker start jbr-ISSUE84
9. Open files, mouse wheel zoom. Changing editor font sizes multiple times with CTRL-scroll freezes UI.
10. fc-list | wc -l reports 2031 fonts

Or repeat steps 1-5 after building this Dockerfile.txt

[jebeaudet]

On my laptop with ubuntu + cinnamon, I had about 2600 fonts installed. I tried removing libreoffice along with fonts mentioned here which removed ~300 fonts. The biggest package that made a difference was fonts-noto-extra which brought down the fc-list down to 992 entries.

[avu]

@osialr thanks for the investigation and the pull request I'll review it. BTW, have you signed our CLA https://www.jetbrains.com/agreements/cla/ ?

[osialr]

@avu I tried out ideaIC with the last night's JBR build on my laptops and the docker image. In all of them, the UI pauses that I had are essentially gone. Switching back to bundled JBR brought back the UI pauses. So at least for me, the PR did it's job.

Used jbr_jcef-11_0_15-linux-x64-b2043.56.tar.gz from Release 11_0_15-b2043.56

[avu]

Good news @osialr, thanks for letting us know!