| Summary: | Reliable way to crash eclispe | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Martin Möbius <m.moebius> |
| Component: | UI | Assignee: | Martin Aeschlimann <martinae> |
| Status: | RESOLVED DUPLICATE | QA Contact: | |
| Severity: | major | ||
| Priority: | P3 | CC: | philippe_mulet |
| Version: | 2.0 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 2000 | ||
| Whiteboard: | |||
|
Description
Martin Möbius
In Build 20020205, the UI freezes for about two minutes, but it eventually returns and displays all types in the view. Most of this time seems to be taken by sorting and displaying the results -- moving to JDTUI for comment. Just noticed a problem with my computer, perhaps it's a bug with my ram. Will test my machine and report again Exchanged ram. Think i got an explanation. If i start without -vmargs -Xmx256M it kills eclipse, with it all works fine (just too slow). In addition, if i execute the operation successfully, than close eclipse an restart without the -vmargs eclipse crashes too. Some more observations: * computing the type hierarchy on Object with all its subtypes is memory intense. In my workspace the memory consumption went up by 55 MB (starting with 115MB). It isn't the UI since I do the operation in the super types view. This means only Object will show up as a result. * switching the view to the subtypes view is slow again > 2 minutes and the memory consumption goes up by another 50 MB. The tree is flat and even though we only show the immediate children you end up with a tree with thousands of nodes. Opening a type hierarchy on object is not useful but we should handle it better. Questions: Q1) 55 MB for computing the type hierarchy is high. Philippe is there anything core can do to reduce the memory consumption? Q2) switching to the subtypes hierarchy is slow again, does all the time go into creating tree items? We should investigate. Proposals for improving (in addition to reducing the memory footprint): a) show a progress monitor with the option to cancel. b) warn the user before starting the operation that it can take a while c) don't allow opening a type hierarchy on Object. Given that opening a type hierarchy on Object isn't useful option c) would be a pragmatic but acceptable solution. I like better the allowing to cancel approach, since JCL developpers might care about Object hierarchies. Computing the hierarchy for Object is memory intensive, since it is pretty much resolving the entire workspace content dynamically. No matter how optimized we are, it will still take cycles. We will investigate hierarchy performance when doing a performance pass (likely around M5). |