Created attachment 125369 [details]
nps snapshot

*** Bug 218910 has been marked as a duplicate of this bug. ***

Created attachment 126274 [details]
nps snapshot

Code completion is waiting for an extremely slow call to org.openide.util.Utilities.getUsableScreenBounds()

Some information about my system configuration:
>10 GB ram, Nvidia graphics card, dual screen setup with 2x 2560x1600 resolution, Ubuntu Linux

Netbeans UI feels kind of sluggish, I am not sure if it is due to being Linux or the large resolution.

Eager to help out with more tests.

(In reply to comment #4)
> Code completion is waiting for an extremely slow call to
> org.openide.util.Utilities.getUsableScreenBounds()

Stando, another issue related to issue 218895?

Looks like a problem in XToolkit as sun.awt.X11.XToolkit.getScreenInsets() is doing some wild things which can take more than half a minute to complete.

A workaround is to use -J-Dnetbeans.screen.insets=0,0,0,0 command-line switch.

This problem isn't related to #218895

I will test the work-around and report back in the next days.

Additional remarks: I run Netbeans on the primary monitor, the secondary is left-of the primary monitor. Due to the nvidia proprietary driver my comments should be taken with a grain of salt, I always get confused how nvidia handles this stuff. (Most applications get the impression that I have in fact only one big screen.)
When I execute code completion I notice sometimes flickering, resizing grey boxes at the position the hints will finally appear when Netbeans finally decides what to display. I assumed this is due to the nightly builds, the behaviour is much slower than Netbeans 7.2 in this aspect. (Up to the point that I currently try to avoid code completion since it slows me down so much.)
I will try to verify this with a different machine.

Tested with 201210250921 even without the -J-insets switch, it feels a hell of a lot faster.
With the -J-Dnetbeans.screen.insets=0,0,0,0  command line switch, auto-completion hints are on the wrong screen (dual screen setup), the performance does not feel different.
(With the insets specified it looks to me like the http://netbeans.org/bugzilla/show_bug.cgi?id=213733 issue seems to be solved by a JDK update.)

I didn't change the JDK, though.

java version "1.7.0_09"
Java(TM) SE Runtime Environment (build 1.7.0_09-b05)
Java HotSpot(TM) 64-Bit Server VM (build 23.5-b02, mixed mode)

I just had the issue happening again
"It has now been added to the database with id #622144. It has been classified as a duplicate of report #192707."

What I noticed: The performance seems to be related to the number of possible suggestions.
When there is just 1 oder 3 options to choose from, it is blazingly fast. When there are many suggestions it is very slow.

Under that circumance I can confirm that
"-J-Dnetbeans.screen.insets=0,0,0,0"
fixes the issue, but the popups are then on the wrong display.

Without deep knowledge what is happening under the hoods - could the insets be cached some way to mitigate the problem?

Looks like gathering the screen insets is a rather slow call on my machine:

Total time for 100 iterations 12250
Per iteration: 122
(On my current machine, 16GB ram, Nvidia graphics card, dual screen 2560x1600x2)
I used an older machine  (5 year old T60 laptop with 2gb ram, ati graphics card, 1400x1050 screen, 64bit server vm as well) as reference:
Total time for 10000 iterations 2123
Per iteration: 0

That is orders of magnitude difference.

I used this to measure the time taken to get the insets, but having no deep experience with AWT/Swing it might measure the wrong thing:

public class ScreenInsets
{
    public static void main(String[] args)
    {
        runInsets();
    }
    
    public static void runInsets()
    {
        int ITERATIONS = 100;
        GraphicsConfiguration graphicsConfiguration = new Frame().getGraphicsConfiguration();
        Toolkit defaultToolkit = Toolkit.getDefaultToolkit();
        
        long start = System.currentTimeMillis();
        
        int i = ITERATIONS;
        
        while(i-- > 0)
        {
            defaultToolkit.getScreenInsets(graphicsConfiguration);
            
        }
        
        long end = System.currentTimeMillis();
        System.out.println(String.format("Total time for %d iterations %d",ITERATIONS, end-start));
        System.out.println(String.format("Per iteration: %d", (end-start)/ITERATIONS));
    }

}

After connecting a second screen to the Thinkpad, the resolution was
1400x1050 + 1920x1200
The time changed to
Total time for 10000 iterations 327851
Per iteration: 32
Total time for 100 iterations 7357
Per iteration: 73


One CPU core was saturated during the test.

Operating system: Ubuntu 12.10, 64bit
CPU: Intel (Thinkpad), AMD (Desktop)
Graphics: ATI (Thinkpad), AMD (Desktop)
Desktop Environment: Gnome (they call it "classic" or "fallback session")

I think this issue has impact on various points of perceived speed of Netbeans IDE, maybe even the Netbeans Platform.

During my testing the load was generated by the X server process, not the java process.
Maybe this is something that can not be fixed easily on that low layer.

Is caching the insets a workaround?

It seems like "the other IDE" had a similar problem in dual screen setups with Java 7, as described in these issues:
http://youtrack.jetbrains.com/issue/IDEA-73128
http://youtrack.jetbrains.com/issue/IDEA-72050

It looks like they tweaked the getScreenInsets Method somehow.
According to their (Open Source) code they use a cache for Linux and Solaris environments for the insets:

http://grepcode.com/file/repository.grepcode.com/java/ext/com.jetbrains/intellij-idea/11.0/com/intellij/ui/ScreenUtil.java

Stando, can you comment on the notes above?

I have tested a (very simplistic) cache, it indeed solves the problem.
It makes Netbeans fly like never before on my machine :)

I will attach a patch, while assuming it will not meet the coding conventions and/or quality of Netbeans, since I have no experience with the platform.

Created attachment 126804 [details]
Cache calls to getScreenInsets for 10 seconds

core-main d84cc3c44e7c

Thanks for nice and clean patch!

Integrated into 'main-golden', will be available in build *201211020001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/d84cc3c44e7c
User: S. Aubrecht <saubrecht@netbeans.org>
Log: #219507 - cache usable screen bounds on some platforms to work around performance problems

*** Bug 220370 has been marked as a duplicate of this bug. ***