Community
Participate
Working Groups
The SourceTypeConverter has the following condition for a diet parse: if (this.has1_5Compliance && ((CompilationUnitElementInfo) ((JavaElement) this.cu).getElementInfo()).annotationNumber > 10) { // experimental value While the purpose of the diet parse (in case the number of annotations being more than 10) seemed to be better performance, the question is: In the case where the client is not interested in LOCAL_TYPE, should there be a full parse at all? Deciding to do or not do something based on this number alone is unconvincing. I suggest we do parse the methods only when the clients are interested in them (i.e. 'flags' contains LOCAL_TYPE). This needs to be investigated, though, for any missing functionality.
Not sure how many times we actually end up doing a diet parse. Please clean up that code is necessary, but make sure we don't drop in performance.
What is motivating the change ?
(In reply to comment #2) > What is motivating the change ? One of the eclipse clients ran in to a performance problem. On investigation, we found that they were using IType#resolveType() heavily. I believe doing a full parse could have also contributed to the problem, albeit not in a big way. I will use this bug to investigate that, come up with some numbers in terms of performance and make changes if required.
Interestingly some of the tests reveal that diet parsing take more system resources than a full parsing. For instance resolving type JavaCore in the context of JavaModelManager produces the following numbers: Full parsing ------------- Scenario 'org.eclipse.jdt.core.tests.performance.FullSourceWorkspaceTypeHierarchyTests#testTypeResolve()' (average over 10 samples): Used Java Heap: 9.54M (95% in [9.53M, 9.55M]) Working Set: 197.6K (95% in [-104.11K, 499.31K]) Committed: 153.2K (95% in [-208.04K, 514.44K]) Working Set Peak: 65.6K (95% in [-64.82K, 196.02K]) Elapsed Process: 476ms (95% in [411ms, 541ms]) Kernel time: 4ms (95% in [-2ms, 12ms]) Page Faults: 85 (95% in [7, 164]) CPU Time: 464ms (95% in [365ms, 562ms]) GDI Objects: 0 (95% in [0, 0]) Diet parsing ------------- Scenario 'org.eclipse.jdt.core.tests.performance.FullSourceWorkspaceTypeHierarchyTests#testTypeResolve()' (average over 10 samples): Used Java Heap: 10.28M (95% in [9.81M, 10.74M]) Working Set: 1.06M (95% in [-1.2M, 3.31M]) Committed: 973.2K (95% in [-2.31M, 4.22M]) Working Set Peak: 1.02M (95% in [-1.2M, 3.24M]) Elapsed Process: 3.86s (95% in [3.52s, 4.21s]) Kernel time: 7ms (95% in [0ms, 15ms]) Page Faults: 441 (95% in [-146, 1.03K]) CPU Time: 3.3s (95% in [3.12s, 3.47s]) GDI Objects: 0 (95% in [0, 0]) In the latter case, we do a full parse only when the clients are interested in LOCAL_TYPE. This change causes some existing tests to fail. They might have to test the LOCAL_TYPE too. But I guess I will close the defect as the effort may not be worth it. Srikanth, any idea why a diet parse would be costlier?
(In reply to comment #4) > Interestingly some of the tests reveal that diet parsing take more system > resources than a full parsing. For instance resolving type JavaCore in the > context of JavaModelManager produces the following numbers: Where are these numbers from ? (How did you collect them ?) > In the latter case, we do a full parse only when the clients are interested in > LOCAL_TYPE. This change causes some existing tests to fail. They might have to > test the LOCAL_TYPE too. But I guess I will close the defect as the effort may > not be worth it. > > Srikanth, any idea why a diet parse would be costlier? Signt unseen, no idea. Can you take a profile and see what it shows ?
Created attachment 184921 [details] Performance test used (In reply to comment #5) > Where are these numbers from ? (How did you collect them ?) The numbers are from the attached performance test. The tests was run with the source files as they were and with additional annotations for completeness. Results were similar. > Signt unseen, no idea. Can you take a profile and see what it shows ? I will see what happens.
(In reply to comment #6) > > Signt unseen, no idea. Can you take a profile and see what it shows ? > > I will see what happens. Looks like in most cases, the SourceTypeConverter does most of the work instead of doing a full parse. A regular parse is only called either for a field or when an exception occurs during the process of conversion. So, that explains the diet parse being slower. It is not a comparison of diet parse vs. regular parse but selective conversion vs. diet parsing. So, it is reasonable to say that under most circumstances, the existing code works just fine.
Resolving as INVALID.
Verified.
