Summary: | Revisit conditional diet parse in SourceTypeConverter.convert(ISourceType[], CompilationResult) | ||||||
---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Jay Arthanareeswaran <jarthana> | ||||
Component: | Core | Assignee: | Jay Arthanareeswaran <jarthana> | ||||
Status: | VERIFIED INVALID | QA Contact: | |||||
Severity: | normal | ||||||
Priority: | P3 | CC: | Olivier_Thomann, srikanth_sankaran | ||||
Version: | 3.7 | Keywords: | performance | ||||
Target Milestone: | 3.7 M4 | ||||||
Hardware: | All | ||||||
OS: | All | ||||||
Whiteboard: | |||||||
Attachments: |
|
Description
Jay Arthanareeswaran
2010-11-08 02:59:43 EST
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. |