Bugzilla – Full Text Bug Listing
| Summary: | Scalability enhancment to the flexible hierarchy's IAsynchronousContentAdapter | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Pawel Piech <pawel.1.piech> |
| Component: | Debug | Assignee: | Michael Rennie <Michael_Rennie> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | ||
| Version: | 3.3 | ||
| Target Milestone: | 3.3 M4 | ||
| Hardware: | PC | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | 156883 | ||
| Bug Blocks: | 159682 | ||
As we solidy the flex hierarchy APIs in 3.3, we're attempting to use the JFace viewer implementation rather than our own custom viewers. Since the ILazyTreeContentProvider is based on "number of children" and "get children at an offset", it becomes easier to mimic this pattern in the underlying content adapter. See bug 153500. In the patch "coalesce content requests", an implementation is provided that coalesces content request from the virtual viewer, so adjacent children are retrieved all at once (that come within a 10ms time period). This seems like a promising approach. Since the JFace viewer API does not use the "hasChildren", it's hard to use in our API effectively. I may enter this request against JFace so it can be supported at the viewer level first. This is addressed in the "viewer_rework_3_3" branch. We are now using the "lazy tree path content provider". We ask elements if they have children, and we only retrieve the visible children in subranges as they are exposed. Marking fixed. Please verify, Mike, verified |
There is a potential scalability limitation built into the current IAsynchronousContentProvider interface. This limitation has to do with the fact that the retrieveChildren() method expects the adapter to create an array of objects representing all the children of the node. If the number of chilren goes into 100,000+ the performance of the flexible hierarchy views could degrate significantly. Since the current IAsynchronousContentAdapter is perfectly sufficient for 99% of the cases, a simple way to address this problem could be to have an optional extension of this interface: interface IAsynchronousContentAdapterExtension extends IAsynchronousContentAdapter { void getCount(Object parent, IPresentationContext context, IContainerRequestMonitor monitor); void retrieveChilrenSubset(int startIndex, int endIndex, Object parent, IPresentationContext context, IChildrenRequestMonitor monitor); } There are a lot of ways to design these interfaces and the above is just a suggestion, but there are a couple of things to keep in mind: 1) isContainer() query can be a lot more efficient than getCount() for some types of data. So calling getCount() just to paint the "+" on some nodes would be problematic. 2) Even if a range of data is requested (startIndex, endIndex), it would be nice if the adapter could provide children to the IChildRequestMonitor, which are outside of the requested range. This is because some data providers retrieve data chunks of a particular size. 3) From the adapter's point of view, it doesn't matter if the AsynchronousTreeModel is based on JFace TreeViewer directly or not.