Bug 185037 - Optimization opportunity in MethodVerifier
Summary: Optimization opportunity in MethodVerifier
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.3   Edit
Hardware: PC All
: P3 normal (vote)
Target Milestone: 3.4 M1   Edit
Assignee: JDT-Core-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-05-02 03:11 EDT by Maxime Daniel CLA
Modified: 2007-08-03 10:26 EDT (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Maxime Daniel CLA 2007-05-02 03:11:02 EDT
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.
Comment 1 Kent Johnson CLA 2007-06-19 16:10:03 EDT
This was done in May.
Comment 2 Maxime Daniel CLA 2007-06-20 08:54:51 EDT
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?
Comment 3 Maxime Daniel CLA 2007-06-26 07:10:04 EDT
Kent, any further comment?
Comment 4 Kent Johnson CLA 2007-06-26 15:36:08 EDT
Added a couple length > 1 checks.

No reason to do the assignment inside the if test.
Comment 5 Maxime Daniel CLA 2007-06-27 01:27:49 EDT
(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. 

Comment 6 Frederic Fusier CLA 2007-08-03 10:26:02 EDT
Verified (with v_804 code) for 3.4M1 using build I20070802-0800.