Community
Participate
Working Groups
I20070501-0010 / v_754 Reviewing bug 184293, I wondered how length value would be distributed in typical settings (so as to avoid the call to findOverriddenInheritedMethods altogether when length is 1). I've ironed out some stats on the value of the length parameter of findOverriddenInheritedMethods using a full source workspace. My findings on build I20070501-0010 are the following: Full source workspace stats Length 1 2 3 TOTAL Raw 64565 1627 5 66197 Percent 97,53% 2,46% 0,01% 100,00% I believe this is worth some consideration. Beyond the obvious (condition the call to findOverriddenInheritedMethods), there might be an opportunity to segregate the 1 case further in our code.
This was done in May.
I believe we could do more without over investing. The following patch goes a bit further (saves one test and one assignment in most frequent case), and the other calling point of findOverriddenInheritedMethods could also be optimized: ### Eclipse Workspace Patch 1.0 #P org.eclipse.jdt.core Index: compiler/org/eclipse/jdt/internal/compiler/lookup/MethodVerifier.java =================================================================== RCS file: /cvsroot/eclipse/org.eclipse.jdt.core/compiler/org/eclipse/jdt/internal/compiler/lookup/MethodVerifier.java,v retrieving revision 1.88 diff -u -r1.88 MethodVerifier.java --- compiler/org/eclipse/jdt/internal/compiler/lookup/MethodVerifier.java 5 Jun 2007 18:06:11 -0000 1.88 +++ compiler/org/eclipse/jdt/internal/compiler/lookup/MethodVerifier.java 20 Jun 2007 12:51:37 -0000 @@ -236,8 +236,9 @@ // no op before 1.5 } void checkInheritedMethods(MethodBinding[] methods, int length) { - int[] overriddenInheritedMethods = length > 1 ? findOverriddenInheritedMethods(methods, length) : null; - if (overriddenInheritedMethods != null) { + int[] overriddenInheritedMethods; + if (length > 1 && + (overriddenInheritedMethods = findOverriddenInheritedMethods(methods, length)) != null) { // detected some overridden methods that can be ignored when checking return types // but cannot ignore an overridden inherited method completely when it comes to checking for bridge methods int index = 0; Or did you optimize the calling point's calling points?
Kent, any further comment?
Added a couple length > 1 checks. No reason to do the assignment inside the if test.
(In reply to comment #4) > No reason to do the assignment inside the if test. Yes, I believe it's a matter of taste. Not mine either, but Philippe told me 'we used to do it that way' when I joined the team two years ago.
Verified (with v_804 code) for 3.4M1 using build I20070802-0800.