Bug 221862 - Netbeans feels sluggish on large screen (menu open/close, context menu)
Netbeans feels sluggish on large screen (menu open/close, context menu)
Status: RESOLVED WONTFIX
Product: platform
Classification: Unclassified
Component: JDK Problems
7.3
PC Linux
: P3 with 3 votes (vote)
: TBD
Assigned To: Stanislav Aubrecht
issues@platform
http://bugs.sun.com/bugdatabase/view_...
jdk_bug_8004103
: JDK_1.7
: 224357 235881 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-11-09 22:00 UTC by everflux
Modified: 2013-09-25 13:37 UTC (History)
7 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
Hovering over main menu entries (22.58 KB, application/octet-stream)
2012-11-09 22:01 UTC, everflux
Details
first messages log (50.79 KB, text/x-log)
2012-11-11 11:02 UTC, everflux
Details
second messages log (95.90 KB, application/octet-stream)
2012-11-11 11:02 UTC, everflux
Details
third messages (150.73 KB, application/octet-stream)
2012-11-11 11:02 UTC, everflux
Details
Minimizing and restoring netbeans window 3 times, feels slow/grey area shown for a second or two (24.64 KB, application/octet-stream)
2012-11-11 11:40 UTC, everflux
Details
Opening menu on JDK 6 (19.53 KB, application/octet-stream)
2012-11-22 09:53 UTC, everflux
Details
Opening menu on JDK 7 (27.02 KB, application/octet-stream)
2012-11-22 09:53 UTC, everflux
Details

Note You need to log in before you can comment on or make changes to this bug.
Description everflux 2012-11-09 22:00:44 UTC
[ 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.
Comment 1 everflux 2012-11-09 22:01:12 UTC
Created attachment 127513 [details]
Hovering over main menu entries
Comment 2 Tomas Hurka 2012-11-11 10:56:18 UTC
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.
Comment 3 everflux 2012-11-11 11:02:02 UTC
Created attachment 127544 [details]
first messages log
Comment 4 everflux 2012-11-11 11:02:26 UTC
Created attachment 127545 [details]
second messages log
Comment 5 everflux 2012-11-11 11:02:57 UTC
Created attachment 127546 [details]
third messages
Comment 6 everflux 2012-11-11 11:09:16 UTC
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.
Comment 7 everflux 2012-11-11 11:39:21 UTC
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.
Comment 8 everflux 2012-11-11 11:40:02 UTC
Created attachment 127547 [details]
Minimizing and restoring netbeans window 3 times, feels slow/grey area shown for a second or two
Comment 9 Petr Cyhelsky 2012-11-12 10:08:00 UTC
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.
Comment 10 everflux 2012-11-18 09:27:25 UTC
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")
Comment 11 everflux 2012-11-22 09:53:14 UTC
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)
Comment 12 everflux 2012-11-22 09:53:40 UTC
Created attachment 128248 [details]
Opening menu on JDK 6
Comment 13 everflux 2012-11-22 09:53:59 UTC
Created attachment 128249 [details]
Opening menu on JDK 7
Comment 14 everflux 2012-11-22 10:32:43 UTC
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.
Comment 15 Stanislav Aubrecht 2012-11-28 14:52:48 UTC
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.
Comment 16 everflux 2012-11-28 15:12:48 UTC
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).
Comment 17 Stanislav Aubrecht 2012-11-28 15:34:57 UTC
(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.
Comment 18 everflux 2012-11-30 22:41:07 UTC
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
Comment 19 Stanislav Aubrecht 2012-12-03 09:31:31 UTC
(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.
Comment 20 Stanislav Aubrecht 2013-01-07 10:29:18 UTC
*** Bug 224357 has been marked as a duplicate of this bug. ***
Comment 21 mclaborn 2013-01-07 14:53:19 UTC
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.
Comment 22 everflux 2013-03-10 12:15:18 UTC
Result from further testing:
Using plain Gnome 3 fixes all performance problems!

If you require Ubuntu/Compiz, JDK 6 works fast as well.
Comment 23 Petr Cyhelsky 2013-09-25 13:02:00 UTC
*** Bug 235881 has been marked as a duplicate of this bug. ***
Comment 24 mclaborn 2013-09-25 13:37:44 UTC
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.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo