Community
Participate
Working Groups
I20060315-1200 I found this while digging into bug 133025. In 3.2 Debug added some code that requests the Java element adapter for an IFile (that's OK). This results in a call to JavaCore.create(IFile). Even though the CU is in the model all checks are made before the CU is returned and the Scanner is consulted, see the stack trace below. NOTE: this is the same behavior as in 3.1 (and maybe before) and not a regression in JDT Core but since many clients are either using JavaCore.create(IFile) or IFile.getAdapter(IJavaElement.class) it could be a good performance benefit if this could be avoided. Thread [main] (Suspended (breakpoint at line 834 in Scanner)) owns: Class<T> (org.eclipse.jdt.core.JavaConventions) (id=270) owns: RunnableLock (id=310) Scanner.getNextToken() line: 834 JavaConventions.scannedIdentifier(String) line: 89 JavaConventions.validateIdentifier(String) line: 232 Util.isValidFolderNameForPackage(String) line: 1320 Util.packageName(IPath) line: 1474 JavaModelManager.determineIfOnClasspath(IResource, IJavaProject) line: 830 JavaModelManager.createCompilationUnitFrom(IFile, IJavaProject) line: 749 JavaModelManager.create(IFile, IJavaProject) line: 660 JavaModelManager.create(IResource, IJavaProject) line: 624 JavaCore.create(IResource) line: 1378 ResourceAdapterFactory.getAdapter(Object, Class) line: 38 AdapterFactoryProxy.getAdapter(Object, Class) line: 63 AdapterManager.getAdapter(Object, Class) line: 253 File(PlatformObject).getAdapter(Class) line: 65 FileEditorInput.getAdapter(Class) line: 87 ToggleBreakpointAdapter.isRemote(IWorkbenchPart, ISelection) line: 422 ToggleBreakpointAdapter.canToggleWatchpoints(IWorkbenchPart, ISelection) line: 810 RetargetWatchpointAction.canPerformAction(Object, ISelection, IWorkbenchPart) line: 36 RetargetAction$1.run() line: 204 RunnableLock.run() line: 35 UISynchronizer(Synchronizer).runAsyncMessages(boolean) line: 123
This API can be invoked with arbitrary resources, and thus it may not be part of the model.
I know, but thought you could do this: 1. check if it is already in the model 2. if so, return the CU else go through current code path
In order to be acknowledged to be part of the model, it needs to find it based on its handle; which is precisely what is occurring there. Might be improved, but not an immediate change. Also being in the model cache is not guaranteed, we first need to understand if the same IFile is used all the time; and if so, why aren't clients keeping the handle ? Alternatively, the factory could remember recent handles...
Post 3.2
Can this now be reopened for 3.3.?
Reopening to consider in 3.3
To be investigated during 3.3 M7
>To be investigated during 3.3 M7 OK. So the result was that it doesn't pay off? What about looking into this during RC1?
(In reply to comment #8) > >To be investigated during 3.3 M7 > OK. So the result was that it doesn't pay off? What about looking into this > during RC1? > Sorry I didn't have time to look at this during M7. I'll try to look at it during RC1.
Created attachment 67417 [details] Proposed fix and performance test The fix consists in using the project's cache if it is available. Note the project cache is available only if at least one NameLookup has been created for the project (e.g. for a reconcile, or if IJavaProject#findType(...) has been used) since last time the classpath was updated. Running locally, the test is about 20% faster with the fix.
Fix is OK for me. Just one cosmetic remark on perf test, set-up may be more simple as we already created and stored a working copy on the big project: // setup (force the project cache to be created) IFile file = (IFile) WORKING_COPY.getResource(); getNameLookup(BIG_PROJECT);
Thanks Frederic. Made the change to the test. Fix and test released for 3.3RC1 in HEAD.
There is no background data for this perf test. See performance.FullSourceWorkspaceModelTests#testCreateJavaElement() in last perf results. So this needs to be verified later.
Verified for 3.3 RC1 using performance results of test performance.FullSourceWorkspaceModelTests#testCreateJavaElement() in page http://fullmoon.ottawa.ibm.com/downloads/drops/I20070524-0010/performance/org.eclipse.jdt.core.php?
