Community
Participate
Working Groups
Created attachment 276638 [details] patch for master branch of eclipse.jdt.core Compilation is too slow in a project with many parameterized type arguments. I fixed it. "ParameterizedTypeBinding" has many instance variables, but "hashCode()" uses "ReferenceBinding#hashCode()". This is because "hashCode()" is not reimplemented in "ParameterizedTypeBinding". Therefore, there may be many different "ParameterizedTypeBinding" instances that return the same hash code. As a result, in "TypeSystem", a significant performance degradation occurs due to collision of hash codes in "hashedParameterizedTypes" using "PTBKey" as key. "PTBKey" performs comparison of each element of "TypeBinding[] arguments" with "==" in equals, so if different "ParameterizedTypeBinding" instances exist, different hash codes should be returned.
(In reply to iwa from comment #0) > Created attachment 276638 [details] > patch for master branch of eclipse.jdt.core > > Compilation is too slow in a project with many parameterized type arguments. > I fixed it. Cool. Could you please push the change as a Gerrit patch? https://wiki.eclipse.org/JDT_Core_Committer_FAQ
New Gerrit change created: https://git.eclipse.org/r/132817
Till, the patch looks good, so RC1 as target. WDYT? Can we merge it in M3 already?
See gerrit.
@Till, is RC1 still a realistic target? Would already need +1 from a project lead... I see an updated change in gerrit, but unfortunately no test case. Hence my question: how to gain confidence that the change is improving anything?
(In reply to Stephan Herrmann from comment #5) > @Till, is RC1 still a realistic target? Would already need +1 from a project > lead... > > I see an updated change in gerrit, but unfortunately no test case. Hence my > question: how to gain confidence that the change is improving anything? I currently don't have capacity to recheck this with appropriate diligence, so lets move it to 4.11. As this is only a performance improvement, I wouldn't expect a new test case, but it would be nice if somebody knows an open source project where it makes a noticeable difference.
Motonori, can you please provide some performance data, or better an example of open source code which would show some difference in the compilation performance?
I do not know the OSS project where this problem occurs. Below is the information on our project. - Environment - Eclipse: Spring Tool Suite 4.0.0.RELEASE (JDT: 3.15.0.v20180905-0317) - Plug-ins: Lombok 1.18.0, Checkstyle 8.12.0.201808161509 - Annotation processor: doma 2.19.2 - OS: 16.04.5 LTS (x86_64) / gtk 3.18.9 - Java version: 1.8.0_191 - CPU: 2 cores of the following spec (cloud VM) - model name : Intel Xeon E312xx (Sandy Bridge) - cpu MHz : 1995.394 - cache size : 4096 KB - Memory: 15GB - Project size - Java files: 14,106 - Other resource files: 21,003 - Performance information (duration from start of "Clean all project" until "No operations to display at this time." is displayed) - Original: about 50 min. - Patched (change/132817/2): about 22 min.
OS: 16.04.5 LTS => Ubuntu 16.04.5 LTS
Gerrit change https://git.eclipse.org/r/132817 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=41ed24e39f591a7b5807470ed92379a45d609f3a
(In reply to Eclipse Genie from comment #10) > Gerrit change https://git.eclipse.org/r/132817 was merged to [master]. > Commit: > http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/ > ?id=41ed24e39f591a7b5807470ed92379a45d609f3a Released for 4.11M1 Thanks, Motonori!
Verified for 4.11 M1 with Build id: I20190107-0600 (Verified as mentioned in comment 8)
