There was a performance regression with the new PSI strategy due to #2932.
Expand to see pprof before change (104ms)
Expand to see pprof after change (826ms)
From the pprofs, it looks like the changes in #2932 resulted in calliing PsiTypeElementImpl.getAnnotations() for every element in the source, which added 732ms. It looks like most of that time is spent in AnnotationTargetUtil.isTypeAnnotation() presumably to filter out type-use annotations. This work seems unnecessary in the CollectAnnotatedSymbolsPsiVisitor, since at this stage we're just collecting annotated symbols and we don't really care too much about if they're type-use annotations or not since we can always filter out type-use annotations when a user actually requests an annotation with that exact name. In fact, I think we already technically filter them out in PsiResolutionStrategy.fullyQualifiedJavaAnnotationNamesByElements just by the act of calling PsiElement.getAnnotations() to create that map.
I have some ideas for keeping the changes #2932 while avoiding the performance costs, e.g. by just iterating through the PsiElement's children and seeing if there are any PsiAnnotations, but we'll need to make sure that approach is robust and actually fixes the performance issues.
For now, can we just revert the changes in #2932 and do another KSP release to avoid the regression?
There was a performance regression with the new PSI strategy due to #2932.
Expand to see pprof before change (104ms)
Expand to see pprof after change (826ms)
From the pprofs, it looks like the changes in #2932 resulted in calliing
PsiTypeElementImpl.getAnnotations()for every element in the source, which added732ms. It looks like most of that time is spent inAnnotationTargetUtil.isTypeAnnotation()presumably to filter out type-use annotations. This work seems unnecessary in theCollectAnnotatedSymbolsPsiVisitor, since at this stage we're just collecting annotated symbols and we don't really care too much about if they're type-use annotations or not since we can always filter out type-use annotations when a user actually requests an annotation with that exact name. In fact, I think we already technically filter them out inPsiResolutionStrategy.fullyQualifiedJavaAnnotationNamesByElementsjust by the act of callingPsiElement.getAnnotations()to create that map.I have some ideas for keeping the changes #2932 while avoiding the performance costs, e.g. by just iterating through the PsiElement's children and seeing if there are any PsiAnnotations, but we'll need to make sure that approach is robust and actually fixes the performance issues.
For now, can we just revert the changes in #2932 and do another KSP release to avoid the regression?