Annotator is very slow

已回答

Hello,

In my custom language project, the annotator would query StubIndex once for each PsiElement, and it will up to 5000~8000 times for one file. This is very slow(about 7 seconds).

 

The results of those query are the same. I want to store the results  temporarily, but the comments in interface Annotator says “DO NOT STORE any state inside annotators.”

Then, what I can to speed up the Annotator?

1

Is it possible to see your code?

0

There is a lot of code, I cannot share it all. Which part do  you have question?

The Pseudocode is :

public void annnotae(PsiElement element, AnnotationHolder hoder) {

     if (elemement instaceof VarDeclareStmt) {

          Colletion<String> allVars = VarIndex.allKeys(project, file); 

          if( ! allVars.contains(element.getText()) {

              TextRange range = new TextRange(element.getTextRange().getStartOffset(), 
element.getTextRange().getEndOffset());

               holder.createErrorAnnotation(range, "Undeclared Var")
.registerFix(new UndeclaredVarQuickFix(element, element.getText()));

          }

     }

}

Because there are 5000~8000 Var Declare statement in one source file, the annotate function would be call many times. This reduces the performance a lot. If I modify the source file, it seems the annotate will be called all over again.

0

Pseudocode is nice, but real code is better, because it may be implementation problem. 

What is your VarIndex? What kind of collection is returned? Why annotator, not inspection?

 

0

VarIndex is a StubIndex which actually consumed most of the time. It's been implemented in this way:

public static Collection<String> allKeys(Project project, PsiFile file) {
Set<String> allKeys = ContainerUtil.newTroveSet();
StubIndex.getInstance().processAllKeys(KEY, Processors.cancelableCollectProcessor(allKeys),
GlobalSearchScope.fileScope(file), null);
return allKeys;
}

The SDK says annotator has a better performance than inspection, so I did not try inspection.

0

1. I'd made an inspection for this. It allows to have a common data - e.g. this set, which must not be computed for each element for sure.

2. Local variables probably should not be resolved with index, but using treeWalkUp.

3.Why do you need to create this set, instead of using !StubIndex.getElements(Key, element.getText(),project, GlobalSearchScope.fileScope(file)).isEmpty() ?

0

Method 3 is a good way. It decreases 80% of the time consumption and it's acceptable now. 

Method 2, which I don't know it before, might be another good choice.

@Alexandr, thank you very much, it helps me a lot.

0

请先登录再写评论。