Community
Participate
Working Groups
1. Create a workspace that has a lot 30,000 errors. 2. Bring up the tasks view. 3. Wait five minutes for the tasks view to come up, unable to do anything else because it's hanging the UI thread. If possible, the work that goes on behind the scenes for the tasks view (marker management?) should happen off the UI thread. Alternatively, when the number of errors is greater than a certain threshold (say, 500), the user should be prompted, "You have 30,000 errors. Do you really want to see them all? Yes/No" A tasks view with 30,000 errors in it is useless.
Couple problems here: First 30,000 markers are actually being created. This is done by the Java Component. Second, actually creating the TableItems for 30,000 elements takes a huge amount of time. The TaskView not innocent either, it could use a different visual presentation to minimize the number of items that are initially displayed. Moving to SWT for comment as the last time this problem was looked at the time to create the TableItems was taking "most" of the time. Is there anything that SWT can do to improve the widget behavior?
_Hypothetically_, If we increased the performance of the widget by a factor of 5 (which would likely be exceedingly difficult), *and* we were the sole cause of the performance problem, the user would still wait for a full minute in the senario described by this PR. More than anything else, this points out the fundamental flaw: The only long term solution to this problem is for the u/i to lazily populate the table in the same way the windows explorer handles the displaying of files.
It would also be great if 30,000 markers were not really being created. Are there any plans from the JDT team to address this?
There are two problems: - the Task View presentation doesn't scale - 30'000 problem markers are not helpful to the user. There was discussion on constraining the number of problem markers per project to a threshold. Philippe what is the current thinking on having such a constraint?
Moving to core
The treshold hasn't yet been implemented. Beside, we could also consider preventing the build to run in presence of classpath problems. Note: even with 1000 problems, the task list seems overhelmed (takes seconds to update) where the package view seems to handle many more items...
Another solution would be to add page up/down buttons to the table and display only the first 100 or so in the widget. To see the next hundred, the user would click one of the buttons. It's the same idea that search engines use so that you aren't overwhelmed by results.
This is the error threshold DCR (not warnings). Even though the builder is better dealing with some broken situations (inconsistent binaries), it can still be fooled by wrong classpaths (e.g. missing implementation in prereq projects, but rt.jar is there, this results in lots of complaints).
*** Bug 8339 has been marked as a duplicate of this bug. ***
Problem count has been reduced in case not finding Objec, need to investigate some more to see if this scenario is still as bad.
Closing this PR since the UI added a limit on the number of problems displayed in the Tasks list.. plus the compiler/builder made several changes to reduce the most troublesome cases.
Verified
