[Run configurations... dialog] Opening a JUnit configuration takes too long (UI freeze) #8
Comments
…e-jdt#653 Move the logic to search for test methods from `JUnitLaunchConfigurationTab` to `TestSearchEngine::findTestMethods`. Extract the whole logic for caching the results into `TestMethodsCache` (new class) and do the whole searching and caching more efficiently i.e. only when necessary and showing the progress with a monitor by using `ModalContext::run` Fixes vi-eclipse/Eclipse-JDT#8 Contributes to eclipse-jdt#653
HeikoKlare
added
JDT
|
Transferred to eclipse-jdt/eclipse.jdt.ui#683 |
…e-jdt#653 Move the logic to search for test methods from `JUnitLaunchConfigurationTab` to `TestSearchEngine::findTestMethods`. Extract the whole logic for caching the results into `TestMethodsCache` (new class) and do the whole searching and caching more efficiently i.e. only when necessary and showing the progress with a monitor by using `ModalContext::run` Fixes vi-eclipse/Eclipse-JDT#8 Contributes to eclipse-jdt#653
|
@fedejeanne This issue is "open" but has been moved to "Done" in our backlog. Can you please either move it to the proper state in the backlog or document how/why it is done and close it afterwards? |
|
This issue was fixed by eclipse-jdt/eclipse.jdt.ui#675: a progress indicator was added |
|
Do we already have some follow-up issue for improving the handling of the long running action (making it faster, performing it asynchronously, performing it on-demand etc,)? Otherwise we should create that one. |
|
There's eclipse-jdt/eclipse.jdt.core#1214 . Is that what you mean? I haven't spent any time on that though. I could start looking into it next week if you want? It will probably overlap with other performance issues in JDT so it would make sense to go over it together. |
|
That is one option. But we also discussed alternatives/additions like computing the super types asynchronously and disabling the according field in the UI as long as it has not been calculated. Or even to compute whole launch configuration pages asynchronously and show a progress bar in the right side of the launch configurations dialog while loading the information. Those approaches would ensure that even in case of regressions w.r.t. single data providers for the dialog, it will still stay responsibe (i.e., it will avoid performance regressions such as the existing ones). I'd like to have an issue or multiple issues documenting those ideas in our backlog. I would also like to have an issue in our backlog representing eclipse-jdt/eclipse.jdt.core#1214. Otherwise we won't know that there is some JDT issue of that specific interest for us. |
|
I see that we also have vi-eclipse/Eclipse-Platform#3, so it might make sense to document those ideas there and only have a separate JDT-specific backlog item for which the jdt.core issue already exists. |
|
See #16 |
This issue is a specific use case of vi-eclipse/Eclipse-Platform#3. Check that issue for more details and expected behavior.
The text was updated successfully, but these errors were encountered: