Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 311075

Summary:	[common navigator] Java content provider needs to support lazy background load
Product:	[Eclipse Project] JDT	Reporter:	Chuck Bridgham <cbridgha>
Component:	UI	Assignee:	JDT-UI-Inbox <jdt-ui-inbox>
Status:	RESOLVED WORKSFORME	QA Contact:
Severity:	normal
Priority:	P3	CC:	daniel_megert, francisu, markus.kell.r, mcraquel, melickm
Version:	3.6	Keywords:	needinfo
Target Milestone:	---
Hardware:	PC
OS:	Windows XP
Whiteboard:

Description Chuck Bridgham

2010-04-29 13:42:14 EDT

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.

Comment 1 Francis Upton IV

2010-04-29 13:52:52 EDT

(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. :)

Comment 2 Markus Keller

2010-04-29 14:47:45 EDT

(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

Comment 3 Chuck Bridgham

2010-04-29 14:50:59 EDT

(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

Comment 4 Dani Megert

2010-05-11 02:18:31 EDT

Please reopen once you have provided the requested information.