This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
[ BUILD # : 201211062253 ] [ JDK VERSION : 1.7.9 ] OS: Linux, Ubuntu 12.10, Dual screen setup (2x2560x1600) PC: 6 Core AMD, 16GB RAM Netbeans feels much slower on large screens than on a small (Laptop) machine. I have the feeling #219507 was only part of the problem that Netbeans was feeling slow on large screens. I will attach a self profile where I am just moving through the main menu for some seconds, perhaps there are some low hanging fruits. (I have not tested with Java 6, perhaps it is a similar performance issue as Java 7 introduced in #219507 ?) I have no clue how to interpret the self profile, if there is a tutorial on that I could do more analysis before opening a ticket.
Created attachment 127513 [details] Hovering over main menu entries
It looks like JDK issue - most of the time is spent in: sun.awt.X11.XlibWrapper.XGetWindowAttributes[native]() (22.4%) sun.awt.X11.XlibWrapper.XSync[native]() (20.3%) sun.awt.X11.XlibWrapper.XGetWindowProperty[native]() (8.3%) It would be nice if you can attach messages.log. Thanks.
Created attachment 127544 [details] first messages log
Created attachment 127545 [details] second messages log
Created attachment 127546 [details] third messages
XSync seems to be implemented badly when using an nvidia graphics card on Linux, at least this is what I get from this bug report regarding the 'compiz' software: https://bugs.launchpad.net/compiz/+bug/1049214 These guys are implementing a kind of "batch" to avoid multiple calls to XSync through compiz: "This also applies to other synchronous X11 operations such as XGetWindowAttributes, XGetWindowProperty and XQueryTree." I assume that when this bug is fixed in compiz the performance of Netbeans will be much better. (So it might be neither a JDK nor a Netbeans bug in fact) In that case a 'wontfix' for this bug might be appropriate.
I have re-tested with the latest (beta) graphics driver. While the overall desktop performance seems to have increased, Netbeans still feels sluggish and uses quite some cpu power for "simple" stuff. I will attach a self-sample which was recorded while netbeans was minimized and restored three times. Would be really really great if there are low hanging fruits left performance wise.
Created attachment 127547 [details] Minimizing and restoring netbeans window 3 times, feels slow/grey area shown for a second or two
in the latest snapshot most of the time is spent in: com.sun.java.swing.plaf.gtk.GTKEngine.nativeFinishPainting[native]() sun.java2d.loops.FillRect.FillRect[native]() sun.java2d.loops.Blit.Blit[native]() we can't do anything about this. If you have some time to try it, it may be worth trying some non-gtk-related look and feel if it is better there.
Tifference between GTK and Nimbus is huge - when adding --laf com.sun.java.swing.plaf.nimbus.NimbusLookAndFeel Netbeans feels so much better. ("Instant" vs. "1...2... there")
I just tested with JDK 6 compared to JDK 7, can't believe the difference. Netbeans on JDK 6 is lightning fast, even with all the tweaks I tried. This is a very serious performance degradation with JDK 7 on Linux, which should be really investigated in my point of view. I will attach 2 self profiles, both from going just through the main menu items. (JDK 6 is "instant" JDK 7 is about 300 ms to unfold one main menu row)
Created attachment 128248 [details] Opening menu on JDK 6
Created attachment 128249 [details] Opening menu on JDK 7
Tested with the following JDK versions: Java 7u10 Developer Preview Java HotSpot(TM) 64-Bit Server VM (build 23.6-b04, mixed mode), Java 7u12 Developer preview Java 8 EAP Java HotSpot(TM) 64-Bit Server VM (build 25.0-b09, mixed mode) - slightly better percieved performance than JDK 7, but not near the speed of JDK 6 Java 6 Java(TM) SE Runtime Environment (build 1.6.0_37-b06) - way faster than 7 or 8 All results based on the observed speed of opening the main menu, context menus (right click) or pop up hints (code completion) I only changed the JDK, no reboot, no different driver or anything else.
It seems the slow menu problem is caused by XToolkit.getScreenInsetsManually() method which can take a couple of seconds to complete. See also #219507 I will report it to JDK team. The problem with slow native painting on GTK is already reported here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7058937 I'll increase priority of that bug report.
I am not sure this is only GTK since the Metal and Nimbus L&F is slow with JDK 7 as well. I wonder if a similar workaround as for #219507 is possible (caching the getScreenInsetsManually in this case).
(In reply to comment #16) > I am not sure this is only GTK since the Metal and Nimbus L&F is slow with JDK > 7 as well. The painting is related to GTK but menu opening is slow on all look and feels because getScreenInsets() is slow. > > I wonder if a similar workaround as for #219507 is possible (caching the > getScreenInsetsManually in this case). I get it is possible but it needs to be done on JDK level.
A way that might mitigate part of the problem is to change o.n.swing.tabcontrol/beanstubs/org/openide/util/Utilities.java line 409 to read public static Rectangle getUsableScreenBounds(GraphicsConfiguration gconf) { return org.openide.util.Utilities.getUsableScreenBounds(gconf); } I have no idea what side effects that could introduce, though. The workaround from issue #219507 didn't help here, since the "Utility" class exists multiple times and only one did receive the inset cache. You might want to check comment on bug 218895 "UI dialogue boxes open collapsed" as well, since the method redundancy could lead to other problems: http://netbeans.org/bugzilla/show_bug.cgi?id=218895#c16
(In reply to comment #18) > A way that might mitigate part of the problem is to change > o.n.swing.tabcontrol/beanstubs/org/openide/util/Utilities.java > line 409 to read That file isn't part of standard NetBeans build. It's compiled only when tabcontrol module is being built as a standalone JAR. Fixing that class would have no effect on NetBeans performance.
*** Bug 224357 has been marked as a duplicate of this bug. ***
I would like to see this bug remain in "open" status until it is actually fixed. Even if the fix is a JDK/JRE fix, it deserves some attention in the NB realm until it is working well again.
Result from further testing: Using plain Gnome 3 fixes all performance problems! If you require Ubuntu/Compiz, JDK 6 works fast as well.
*** Bug 235881 has been marked as a duplicate of this bug. ***
Just an FYI: I am on Ubuntu 12.04, and recently switch from Unity 3D to Unity 2D to try to diagnose a problem. I found 2D so much faster and responsive that I stayed there. NetBeans is noticably more responsive also - especially in the GUI deisgner.
FWIW, I have been affected by this issue but found an easy workaround: 1. Edit "NETBEANS_HOME/etc/netbeans.conf" 2. Find the line "netbeans_default_options=..." 3. Append the following text at the end of the line (before the closing quotes): -J-Dsun.java2d.opengl=true 4. Reopen netbeans and go to Tools -> Options -> Appearance -> Look and Feel 5. Choose "Metal" and check "Maximize use of native look and feel" 6. Restart netbeans and that's it. Environment info: - Running Ubuntu 14.04 64 bit - Used to have an old AMD Radeon card (Gallium3D driver); no issue at this point - Replaced the GPU with a bit less older nVidia GeForce 7300 LE; netbeans starts to suffer from this issue (other apps run fine)