Community
Participate
Working Groups
If you are in the Java Perspective with class org.eclipse.jdt.internal.compiler.parser.Parser selected when you hit Ctrl H it can take several seconds to open (as long as 6 seconds). There should be a busy cursor for opening this dialog. As well when I benched the opening of the dialog with the OptimizeIt profiler I found that initializing the selection (JavaSearchPage.initSelections() took 52.8% of the time to open the dialog.
Did you dig into the method? I don't think JavaSearchPage.initSelections() took the time but the JavaModel to do the code resolve. ==> it depends on what's selected. Could you provide the selection because when I tried it it was fast. Maybe there's a bug in the Java Model for the type/code you selected.
It was fast when tired it as well. One difference between Tod's and Dani's workspace could be that Tod has a full source workspace. I also suspect that code resolve is expensive. Showing a busy cursor when bringing up this dialog is fair.
Dani did you try this scenario in the full source workspace?
I tested this in the full workspace scenario (i.e. whole Eclipse as source) against build F1. - Test 1: Start workspace drilled into the package and selected CU, Ctrl+H - Test 2: Start workspace drilled into the package and selected type Parser, Ctrl+H - Test 3: Start workspace opened type Parser and selected Parser, Ctrl+H All tests opened the Java Search page immediately with the right values filled in. Maybe there was a problem in earlier builds or the Lotus Notes was using most of the CPU (that sometimes happens to me).
