Community
Participate
Working Groups
The Common Navigator can hang for an extended period waiting on several content providers to return their children, especially on startup. The content provider with ID: org.eclipse.jdt.java.ui.javaContent seems to cause the most delay, as it depends on java model initialization of the entire workspace in some cases. Does this content provider support a mechanism where a "placeholder" could be returned to the calling viewer while the work of collecting the tree contents be handled by a separate Non-UI job? I noticed the Java Navigator view may have some native support for lazy loading? This is more of a question of support, and a request for an enhancement if this doesn't exist.
(In reply to comment #0) > I noticed the Java Navigator view may have some native support for lazy > loading? If they do, oh goody, then I can do what I always do, just steal the JDT code. :)
(In reply to comment #0) > depends on java model initialization of the entire workspace in some cases. Do you have any traces that show what's taking up time, or concrete scenarios that are slow? (In reply to comment #1) The Package Explorer has no lazy loading, but have some optimizations that should avoid delays on startup: - we never compute children of Java projects or compilation units upfront (i.e. we always show the +) - we don't restore expanded elements on startup - since we don't expand projects, the classpath entries don't need to be resolved on startup
(In reply to comment #2) > (In reply to comment #0) > > depends on java model initialization of the entire workspace in some cases. > > Do you have any traces that show what's taking up time, or concrete scenarios > that are slow? > > > (In reply to comment #1) > The Package Explorer has no lazy loading, but have some optimizations that > should avoid delays on startup: > - we never compute children of Java projects or compilation units upfront (i.e. > we always show the +) > - we don't restore expanded elements on startup > - since we don't expand projects, the classpath entries don't need to be > resolved on startup I'll try to add a stack trace soon, and your right about "startup".. I meant initial load after expanding project nodes. This can trigger a slow load
Please reopen once you have provided the requested information.
