IssueTracker

An observation.

If you split your editor, it happens more likely.

Still very slow in Hedgehog 10

It is not neccessarily the editor split function that causes this issue, but it slows it more when in use.

Added an example picture on how "Performing code analysis" is shown when editor is splitted.

I actually expect that it is necessary with only one process checking one file. Can image that there might be concurrent / "wait-for" problems rising when two or more processes is checking the same file.

Sorry this bug was in limbo; it was unassigned from android-devtools-triage@, then moved and subsequently lost.

Almost all the thread dumps involve ComposePreviewRunLineMarkerContributor:

...
at org.jetbrains.kotlin.idea.caches.resolve.ResolutionUtils.analyze(ResolutionUtils.kt:135)
...
at org.jetbrains.uast.kotlin.KotlinUAnnotationBase$qualifiedName$2.invoke(KotlinUAnnotation.kt:28)
...
at com.android.tools.idea.annotations.AnnotatedMethodsFinderKt.isAnnotatedWith(AnnotatedMethodsFinder.kt:206)
at com.android.tools.idea.compose.preview.PreviewElementFinderUtilsKt.isComposable(PreviewElementFinderUtils.kt:308)
...
at com.android.tools.idea.compose.preview.PreviewElementFinderUtilsKt.getPreviewNodes(PreviewElementFinderUtils.kt:126)
at com.android.tools.idea.compose.preview.PreviewElementFinderUtilsKt.getPreviewElements(PreviewElementFinderUtils.kt:114)
at com.android.tools.idea.compose.preview.PreviewElementFinderUtilsKt.getPreviewElements$default(PreviewElementFinderUtils.kt:113)
at com.android.tools.idea.compose.preview.PreviewElementFinderUtilsKt.hasPreviewElements(PreviewElementFinderUtils.kt:98)
at com.android.tools.idea.compose.preview.ComposePreviewElementKt.isValidComposePreview(ComposePreviewElement.kt:162)
at com.android.tools.idea.compose.preview.runconfiguration.ComposePreviewRunLineMarkerContributor.getInfo(ComposePreviewRunLineMarkerContributor.kt:48)
at com.intellij.execution.lineMarker.RunLineMarkerProvider.getLineMarkerInfo(RunLineMarkerProvider.java:63)
at com.intellij.codeInsight.daemon.impl.LineMarkersPass.queryProviders(LineMarkersPass.java:183)
...

It's hard to say for certain whether ComposePreviewRunLineMarkerContributor is the primary issue (there are other threads running Kotlin resolve too). Still, I plan to defer ComposePreviewRunLineMarkerContributor to run after the main Kotlin highlighting pass in order to reduce analysis lock contention and better reuse cached symbol resolution. Another idea (for compose folks to consider) is to check the "short" name of each annotation before attempting to resolve the fully qualified name. This would probably involve making hasPreviewElements() work with the KtNamedFunction directly, since I don't think UAST exposes the annotation short-name.

Downgrading to P2 for now since this seems like an isolated / uncommon case.

I uploaded ag/25118574 for the "defer ComposePreviewRunLineMarkerContributor" part. Now over to Amaury in case we want to optimize ComposePreviewRunLineMarkerContributor further (e.g. avoid resolving annotation fq names in some cases).

Fixed by http://ag/25262196

Thank you for your patience while our engineering team worked to resolve this issue. A fix for this issue is now available in:

• Android Studio Iguana | 2023.2.1 Canary 13
• Android Gradle Plugin 8.3.0-alpha13

We encourage you to try the latest update.

If you notice further issues or have questions, please file a new bug report.

Thank you for taking the time to submit feedback — we really appreciate it!