Skip to content

Performance regression in PsiResolutionStrategy in KSP 2.3.8 #2948

@bcorso

Description

@bcorso

There was a performance regression with the new PSI strategy due to #2932.

Expand to see pprof before change (104ms) Image
Expand to see pprof after change (826ms) Image

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?

Metadata

Metadata

Assignees

Labels

P1major features or blocking bugsperformanceKSP performance, e.g., reducing build times for users

Type

No fields configured for Task.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions