Comment 1 Darin Wright 2004-08-26 10:36:02 EDT

*** Bug 20487 has been marked as a duplicate of this bug. ***

Comment 2 Darin Wright 2004-09-07 12:48:50 EDT

*** Bug 73339 has been marked as a duplicate of this bug. ***

Comment 3 Darin Wright 2004-09-07 12:49:33 EDT

Luc, please see bug 73339 for another test case.

Comment 4 Luc Bourlier 2004-09-07 20:32:48 EDT

I won.
I get a 10+ minutes UI block if I try to do a code completion in the display
view when the current stack frame is in ASTInstructionCompiler.

Using code assist in the display view is a good way to see the problem, but it's
 not the case I see what looks like the same problem.
I get some bad UI block (~3-4 seconds) every time I use F3 to open a method/type
declaration in a long file, or code assist in the Java editor, when it
references a type with lot of methods.

Every time I generate a thread dump in this cases, I get the same type of stack
trace, it's doing some string concatenation in the NameLookup system.

        In java/lang/StringBuffer.append(C)Ljava/lang/StringBuffer;
        In
org/eclipse/jdt/internal/core/util/Util.concatWith([Ljava/lang/String;C)Ljava/lang/String;
        In
org/eclipse/jdt/internal/core/PackageFragment.getElementName()Ljava/lang/String;
        In
org/eclipse/jdt/internal/core/NameLookup.nameMatches(Ljava/lang/String;Lorg/eclipse/jdt/core/IJavaElement;Z)Z
        In
org/eclipse/jdt/internal/core/NameLookup.seekPackageFragments(Ljava/lang/String;ZLorg/eclipse/jdt/internal/core/IJavaElementRequestor;)V
        In
org/eclipse/jdt/internal/core/NameLookup.findType(Ljava/lang/String;Ljava/lang/String;ZI)Lorg/eclipse/jdt/core/IType;
        In
org/eclipse/jdt/internal/core/SearchableEnvironment.find(Ljava/lang/String;Ljava/lang/String;)Lorg/eclipse/jdt/internal/compiler/env/NameEnvironmentAnswer;
        In
org/eclipse/jdt/internal/core/SearchableEnvironment.findType([C[[C)Lorg/eclipse/jdt/internal/compiler/env/NameEnvironmentAnswer;
        In
org/eclipse/jdt/internal/compiler/lookup/LookupEnvironment.askForType(Lorg/eclipse/jdt/internal/compiler/lookup/PackageBinding;[C)Lorg/eclipse/jdt/internal/compiler/lookup/ReferenceBinding;
        In
org/eclipse/jdt/internal/compiler/lookup/PackageBinding.getType([C)Lorg/eclipse/jdt/internal/compiler/lookup/ReferenceBinding;
        In
org/eclipse/jdt/internal/compiler/lookup/Scope.findType([CLorg/eclipse/jdt/internal/compiler/lookup/PackageBinding;Lorg/eclipse/jdt/internal/compiler/lookup/PackageBinding;)Lorg/eclipse/jdt/internal/compiler/lookup/ReferenceBinding;
        In
org/eclipse/jdt/internal/compiler/lookup/Scope.getTypeOrPackage([CI)Lorg/eclipse/jdt/internal/compiler/lookup/Binding;
        In
org/eclipse/jdt/internal/compiler/lookup/Scope.getType([C)Lorg/eclipse/jdt/internal/compiler/lookup/TypeBinding;
.....


Moving to jdt core for comment, and changing the priority to major, it makes
code assist in the display unusable.

Comment 5 Frederic Fusier 2004-09-13 13:36:10 EDT

Seems to be an impact of element name memory size optimization.
NameLookup.seekPackageFragments(...) can be optimized to avoid to call
getElementName() which is now computed on PackageFragment...

Comment 6 Jerome Lanneluc 2004-09-14 08:05:30 EDT

NameLookup.seekPackageFragments(...) was changed to compare String arrays 
instead of using the package fragment's element name.

Need to write a performance test.

Comment 7 Jerome Lanneluc 2004-09-15 06:24:15 EDT

Added performance test NameLookup2#testPerfSeekPackageFragments()

Comment 8 Frederic Fusier 2004-09-23 10:38:45 EDT

Verified for 3.1 M2 with build I200409230010.