Summary: | Creating the tasks view hangs the UI thread | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Jared Burns <jared_burns> |
Component: | Core | Assignee: | Philipe Mulet <philippe_mulet> |
Status: | VERIFIED WORKSFORME | QA Contact: | |
Severity: | normal | ||
Priority: | P2 | CC: | knut_radloff, philippe_mulet, steve_northover |
Version: | 2.0 | ||
Target Milestone: | 2.0 F2 | ||
Hardware: | Other | ||
OS: | other | ||
Whiteboard: |
Description
Jared Burns
2001-11-21 10:42:37 EST
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 |