Bug 158387 - [variables] Showing variable value takes a long time and creates much garbage
Summary: [variables] Showing variable value takes a long time and creates much garbage
Status: RESOLVED DUPLICATE of bug 148965
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Debug (show other bugs)
Version: 3.2   Edit
Hardware: PC Windows XP
: P3 major (vote)
Target Milestone: ---   Edit
Assignee: JDT-Debug-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: performance
Depends on:
Blocks:
 
Reported: 2006-09-22 16:55 EDT by Nick Edgar CLA
Modified: 2007-02-05 12:13 EST (History)
1 user (show)

See Also:


Attachments
HTML export of YourKit CPU profile (with invocation counts). (6.50 KB, application/zip)
2006-09-22 16:59 EDT, Nick Edgar CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nick Edgar CLA 2006-09-22 16:55:31 EDT
3.2
VM: IBM 1.5.0 SR3

- In a *large* self-hosting workspace,
- Run the target eclipse
- Hit a breakpoint
- select a variable
- it takes several seconds (sometimes 5-10 secs) to show the value, meanwhile the heap status indicator in the host eclipse goes crazy, creating 100s of meg of garbage

I took a trace in YourKit of the host, and it shows one call to JavaDetailFormattersManager.getJavaProject fanning out to ~27000 calls to JarPackageFragmentRoot.initPackageFragToTypes and ~24000 calls to PackageFragmentRoot.getClassFile.
Comment 1 Nick Edgar CLA 2006-09-22 16:59:12 EDT
Created attachment 50737 [details]
HTML export of YourKit CPU profile (with invocation counts).
Comment 2 Nick Edgar CLA 2006-09-22 17:10:02 EDT
My class path may be different than the norm. I have a custom PDE target pointing to a separate Eclipse 3.2 install which has a Links folder with entries pointing to EMF and GEF installs.

That is, under eclipse/links there are two files
emf.link with path=c:/.../emf-2.2
gef.link with path=c:/.../gef-3.2-sdk
Comment 3 Darin Wright CLA 2006-10-04 17:53:00 EDT
Philippe: in order to perform a 'toString()' evaluation for a selected variable, we look up its associated source element to resolve a project in which to perform the compilation for the evaluation. It sounds like this is case with a large number of projects that causes the Java model to open many package fragment roots.

Have there been any changes in the way fragments are opened in 3.3?

FYI, the code we use to find a source file in each root is as follows:

IPackageFragment fragment = fRoot.getPackageFragment(packageName);
if (fragment.exists()) {
	switch (fragment.getKind()) {
		case IPackageFragmentRoot.K_BINARY:
			IClassFile file = fragment.getClassFile(typeName + ".class"); //$NON-NLS-1$
			if (file.exists()) {
				return new Object[]{file};
			}
			break;
		case IPackageFragmentRoot.K_SOURCE:
			String[] extensions = JavaCore.getJavaLikeExtensions();
			for (int i = 0; i < extensions.length; i++) {
				String ext = extensions[i];
				ICompilationUnit unit = fragment.getCompilationUnit(typeName + '.' + ext);
				if (unit.exists()) {
					return new Object[]{unit};
				}	
			}
			break;
	}
	}
Comment 4 Darin Wright CLA 2007-02-05 12:13:08 EST

*** This bug has been marked as a duplicate of bug 148965 ***