IssueTracker

I'm having the same problem. The error highlighting feels very unresponsive. Sometimes I even have to close the file for it to clean the error line from the tab.

It looks like this might be related to the Mac touchbar support. Both of the freezes are pointing to the same stackframes, where it looks like the touchbar support is busy updating an *icon* related to running activities, which seems to be doing something really expensive (parsing manifests), which is then going into class loading.

This is in the run machinery.
"AWT-EventQueue-0" prio=0 tid=0x0 nid=0x0 runnable
     java.lang.Thread.State: RUNNABLE
 (in native)
        at java.util.zip.ZipFile.open(Native Method)
        at java.util.zip.ZipFile.<init>(ZipFile.java:219)
        at java.util.zip.ZipFile.<init>(ZipFile.java:149)
        at java.util.zip.ZipFile.<init>(ZipFile.java:120)
        at com.intellij.util.lang.JarLoader.getZipFile(JarLoader.java:237)
        at com.intellij.util.lang.JarLoader.getResource(JarLoader.java:157)
        at com.intellij.util.lang.ClassPath$ResourceStringLoaderIterator.process(ClassPath.java:346)
        at com.intellij.util.lang.ClassPath$ResourceStringLoaderIterator.process(ClassPath.java:342)
        at com.intellij.util.lang.ClasspathCache.iterateLoaders(ClasspathCache.java:98)
        at com.intellij.util.lang.ClassPath.getResource(ClassPath.java:109)
        at com.intellij.util.lang.UrlClassLoader._findClass(UrlClassLoader.java:237)
        at com.intellij.ide.plugins.cl.PluginClassLoader.loadClassInsideSelf(PluginClassLoader.java:147)
        at com.intellij.ide.plugins.cl.PluginClassLoader.tryLoadingClass(PluginClassLoader.java:74)
        at com.intellij.ide.plugins.cl.PluginClassLoader.loadClass(PluginClassLoader.java:61)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
        at com.android.tools.idea.model.MergedManifest.getApiVersion(MergedManifest.java:540)
        at com.android.tools.idea.model.MergedManifest.syncWithReadPermission(MergedManifest.java:499)
        at com.android.tools.idea.model.MergedManifest$$Lambda$3188/459221649.run(Unknown Source)
        at com.intellij.openapi.application.impl.ApplicationImpl.runReadAction(ApplicationImpl.java:925)
        at com.android.tools.idea.model.MergedManifest.sync(MergedManifest.java:372)
        at com.android.tools.idea.model.MergedManifest.getActivities(MergedManifest.java:550)
        at com.android.tools.idea.run.activity.DefaultActivityLocator.lambda$computeDefaultActivity$0(DefaultActivityLocator.java:79)
        at com.android.tools.idea.run.activity.DefaultActivityLocator$$Lambda$3187/1683877759.compute(Unknown Source)
        at com.intellij.openapi.project.DumbService.lambda$runReadActionInSmartMode$0(DumbService.java:79)
        at com.intellij.openapi.project.DumbService$$Lambda$1109/1543342817.run(Unknown Source)
        at com.intellij.openapi.project.DumbService.runReadActionInSmartMode(DumbService.java:110)
        at com.intellij.openapi.project.DumbService.runReadActionInSmartMode(DumbService.java:79)
        at com.android.tools.idea.run.activity.DefaultActivityLocator.computeDefaultActivity(DefaultActivityLocator.java:78)
        at com.android.tools.idea.run.activity.DefaultActivityLocator.validate(DefaultActivityLocator.java:65)
        at com.android.tools.idea.run.editor.DefaultActivityLaunch$State.checkConfiguration(DefaultActivityLaunch.java:49)
        at com.android.tools.idea.run.AndroidAppRunConfigurationBase.checkConfiguration(AndroidAppRunConfigurationBase.java:113)
        at com.android.tools.idea.run.AndroidRunConfigurationBase.validate(AndroidRunConfigurationBase.java:190)
        at com.android.tools.idea.run.AndroidRunConfigurationBase.checkConfiguration(AndroidRunConfigurationBase.java:123)
        at com.intellij.execution.impl.RunnerAndConfigurationSettingsImpl.checkSettings(RunnerAndConfigurationSettingsImpl.kt:321)
        at com.intellij.execution.RunnerAndConfigurationSettings.checkSettings(RunnerAndConfigurationSettings.java:116)
        at com.intellij.execution.impl.TimedIconCache.calcIcon(TimedIconCache.kt:66)
        at com.intellij.execution.impl.TimedIconCache.access$calcIcon(TimedIconCache.kt:18)
        at com.intellij.execution.impl.TimedIconCache$get$$inlined$write$lambda$1.fun(TimedIconCache.kt:50)
        at com.intellij.execution.impl.TimedIconCache$get$$inlined$write$lambda$1.fun(TimedIconCache.kt:18)
        at com.intellij.ui.DeferredIconImpl.evaluate(DeferredIconImpl.java:282)
        at com.intellij.ui.DeferredIconImpl.retrieveIcon(DeferredIconImpl.java:274)
        at com.intellij.openapi.util.IconLoader.getOrigin(IconLoader.java:829)
        at com.intellij.openapi.util.IconLoader.getDarkIcon(IconLoader.java:502)
        at com.intellij.ui.mac.touchbar.TBItemButton.update(TBItemButton.java:181)
        at com.intellij.ui.mac.touchbar.TBItemAnActionButton.updateView(TBItemAnActionButton.java:162)
        at com.intellij.ui.mac.touchbar.TouchBar.lambda$updateActionItems$5(TouchBar.java:255)
        at com.intellij.ui.mac.touchbar.TouchBar$$Lambda$2023/1091692950.accept(Unknown Source)
        at com.intellij.ui.mac.touchbar.ItemsContainer.lambda$forEachDeep$2(ItemsContainer.java:144)
        at com.intellij.ui.mac.touchbar.ItemsContainer$$Lambda$2024/329411827.accept(Unknown Source)
        at java.util.ArrayList.forEach(ArrayList.java:1251)
        at com.intellij.ui.mac.touchbar.ItemsContainer.forEachDeep(ItemsContainer.java:139)
        at com.intellij.ui.mac.touchbar.TouchBar.forEachDeep(TouchBar.java:236)
        at com.intellij.ui.mac.touchbar.TouchBar.updateActionItems(TouchBar.java:245)
        at com.intellij.ui.mac.touchbar.TouchBar.onBeforeShow(TouchBar.java:229)
        at com.intellij.ui.mac.touchbar.StackTouchBars$TouchBarHolder._setNextTouchBar(StackTouchBars.java:161)
        at com.intellij.ui.mac.touchbar.StackTouchBars$TouchBarHolder.lambda$setTouchBar$0(StackTouchBars.java:145)
        at com.intellij.ui.mac.touchbar.StackTouchBars$TouchBarHolder$$Lambda$2004/1459246220.actionPerformed(Unknown Source)

I've the toolbar disabled, if that information helps

Instead of showing custom buttons, they are fixed to the traditional layout (play, pause, etc.)

I'm working on a Mac mini, so no touch bar. I'm not able to give any logs because I'm out of office until next year.

But something is definitively wrong with 3.3 compared with 3.2. It's much more unresponsive.

Here are the suspects that I've noticed:

1. FrequentEventDetector - Too many events posted, #3. Event: java.awt.event.InvocationE
vent[INVOCATION_DEFAULT,runnable=TransferToEDTQueue[Multiple builds view queue]

The build console view (esp. when it is in tree mode) has had some issues. +cc smithbradley@: Was that issue fixed in 3.3?

2. rpaquay@: I see a constant stream of "DefaultActivityLocator - No launchable activities found, total # of activities: 0".

Miguel - This is not related to touchbar, it is simply the run configuration toolbar doing a check of your current run configuration to see whether it is valid. If you can tell us about why your current run configuration is different that what Studio expects, that may help us. Is your app's default activity not easily locatable due to some special setup you have?

3. Lastly, I see a number of freezes that are supposed to happen once around startup. But it does look like you restarted the IDE multiple times during the day. (e.g 3x on the 19th, 2x on 21st, etc).

I suspect that the biggest issue is probably related to (1) above.

Siva, did you look at the second thread dump in the attachments? It points right to the touchbar support ( com.intellij.ui.mac.touchbar.)   If there's no touchbar being used, but it's a Mac, it's probably code which runs regardless of whether an actual touchbar is present. Which means there isn't some simple way of disabling it.

The other freeze dump does seem to be busy spewing exceptions, but I don't see some obvious culprit from the logs.

My project's structure is described in another bug that I filed the other day -> https://issuetracker.google.com/issues/121006352

The Modules folder contains 26 modules, which I don't think is a lot nowadays. The app depends on some of the modules, and modules have dependencies amongst each other. But, again, nothing out of the ordinary. I don't know if this could be related to the FrequentEventDetector. 26 modules means a lot of tasks written to the build console view.

On the "No launchable activities", I can only think that I don't have a launcher activity in the main manifest, they are in each flavor's manifest

On the reboots, on the 19th I was having issues with some strings not detected. In the end I had to invalidate caches and restart. (I should file a new bug for that problem). I don't know why I rebooted today.

If you come up with more suspects, I'll try to help you.

I'm attaching more thread dumps, I just shared 2 of them before. One of them happened just now, so I'm also attaching the latest log

AlAhliNCB

Same issue, some dumps and idea log. Mac OS

#10 is also an issue with kotlin and AndroidResolveScopeEnlarger.

I was one of the people that brought this up on reddit. I was asked to create a separate ticket. Here it is: https://issuetracker.google.com/issues/122028787

same issue

I'm attaching more logs/thread dumps

Just to be sure, let me ask: do you see the issue consistently on different projects and/or computers or only in your particular setup? Can you see the poor performance (as compared to 3.2) on a newly created project or a project you can share?

I see it consistently on different projects

I see the same issue in Gradle files, in Java it's not as bad

@be...@google.com me and my team were actually seeing this on various machines and seemingly it's been affecting our IDE before 3.3, we just didn't really notice when. I can download older versions of AS and see where it starts to happen. Would that be helpful?

I tried 3.2.1 and it does seem faster. Still not instant, but definitely a lot better.

After downgrading my plugin to 3.2.1 and gradle 4.6 everything is much better, plugin 3.3 is horrible.

I noticed dramatically performance downgrade when I updated from latest stable AS 3.2 to 3.3-RC3. Source file with 400 lines of code now is being analyzed/syntax highlighted for about 5-6 seconds. Before update it was about instant. No more than 1 second. With stable AS 3.3 nothing changed - bad performance. Same thing when I try to commit a file to git from AS. Single file with no more than 500 lines of code can be analyzed for 10-20 seconds before commit happen.

Let me share some thoughts on this, even if just as a note to myself:
- #3: the run configuration icon is chosen on the UI thread fairly regularly, even without the touch bar. That's a bug, since loading manifest merger classes as well as actually merging the manifests takes time, but I don't think it's a regression in 3.3. Also, eventually the performance should stabilize (we keep track of manifest timestamps and don't redo the work) so I assume it's not the problem described here.
- Syntax highlighting is done on the common FJ thread pool, not the UI thread. The FJ pool size is 3 in all the attached logs. In some of them 2 threads are busy building the Room schema (for unused symbol inspection etc.) so that's suspicious. But Room support shipped in 3.2 and I don't think these inspections run before highlighting is done anyway.
- #6: FrequentEventDetector indeed points to a problem with the new build view. It's supposed to have been fixed since, so if would be great if someone who suffers from the performance decrease also tried 3.4 beta 1.
- We will be releasing a fix that should speed up symbol resolution (by caching the resolve scope better) soon, I hope this will help even though I didn't find traces of this problem in the attached logs. Having said that, syntax highlighting happens on the FJ pool and so it may not show in dumps corresponding to UI freezes.
- Some of the logs contain many instances of b/122839542, so maybe that's the real reason.
- DefaultActivityLocator indeed writes a lot of output to the logs (and traverses some XML to produce the log content), so maybe that's part of the problem. We'll have a fix for that as well.

I tried 3.4 Beta 1 and 3.5 Canary 1 with no luck. My journey is being tracked here https://issuetracker.google.com/issues/122028787 Bug has the same title, but different contents.

I tried 3.4 Beta 1 + 3.4 plugin and I didn't see any improvements

Find attached the thread dumps from 3.4 Beta 1

Gradle fails to sync, but that's a different issue

The Android Studio team has identified a latency issue and worked out a fix. The fix will be in the next releases of all 3.3/3.4/3.5. Will update this thread once the new releases are out. Thanks for reporting the bug!

Thanks for the update. Really looking forward to all of the updates. Really appreciate the fix going into 3.3 as well. I was hoping I wasn't going to have to move to a canary release permanently.

Thanks for your work! Looking forward to the next release

For the record, I was wrong about the touch bar: in various places we call into MergedManifest from the UI thread, but updating toolbar icons is handled in the background, unless touch bar is used. So that's a real issue, I filed bug 123339491 to handle that.

Facing the same slow problem on Windows, are the fixes specific for mac and so I should open another issue or are they generic?

This fix mentioned in #24 is not specific to any OS.

Will this be part of AS 3.4-beta2 or is it too late and it will make it into 3.4-beta3?

The fix will be in 3.4 Beta 2.

Just installed Beta 2 and it is indeed a lot faster than before but it's still slow :(

Adding a space in a string in a 1500 line file takes 4 seconds to finish code analysis (Same for adding new code) (Was more than 15/20 seconds before).
In that 1500 line file when having an unused import pressing ctrl+alt+L to reformat + optimize import locks AS for 20+ seconds this have not changed.
But when there's no unused import, ctrl+alt+L now only lock AS for 2/3 seconds when it was also 20+ secs before.

Can't edit but forget to tell Windows 10 / i6850K@4Ghz / 64GB RAM / SSD Samsung 960 Pro, so not limited by the machine and was not the case a few AS version back.

If you can do a Ctrl + Alt + L, then when the IDE is hung, obtain a couple of thread dumps (https://developer.android.com/studio/report-bugs#thread-dump) and attach them here, we can identify the root cause.

Here it is.

dumps.zip correspond to the lock during ctrl alt l
Dump1 is being idle before doing anything.
Dump2 / Dump3 are during the hung

dump-analysis contains 2 dumps during the very slow code analysis.

to...@gmail.com what do you have set in studio.vmoptions? I have a similar machine (maxed out iMac 27inch, 64GB of ram, etc) and have my studio.vmoptions set to -Xmx12g

A little disappointed that this issue isn't completely resolved yet, but it does seem promising that it's getting better. It's just crazy to me that I've spent a few thousand dollars on hardware to make my day to day Android development as productive as possible and I'm hitting this issue.

If you want, you can also check out my issue (with the same title as this one) https://issuetracker.google.com/issues/122028787

I highly recommend you star this issue I created as well, where I ask for specific up to date documentation on what values to set on a very "high end" machine (like you and I both have)
https://issuetracker.google.com/issues/120953354

I had already star the doc for high end machine when it was created ;)
I'm also disappointed that performances goes down when it's written everywhere we improved it :)
I've tested a million settings and for the locks and slow speed nothing impact, I'm also at 12G Xmx.
But you should be happy to have a mac I have a Windows computer as I also play games :p And have to face slow NTFS and gradle is highly impacted too.

To the Google guys, I work a lot by mails with the R8 team to have bug fixed there since a few months as it's more efficient and can provide more sensitive data, so as you can see my mail, do not hesitate to contact me to ask for more details, I'm reactive even if i'm CET TZ :)

I've also been having these issues for a while, 3.4 beta02 hasn't helped much.

I'm on a 2018 Macbook pro 32gb.

I've attached 2 thread dumps:
dump_syntax_highlighting.txt - taken after opening a (kotlin) file and waiting for the syntax highlighting to complete.
dump_code_analysis.txt - taken after making a code change and waiting for code analysis to complete.

Each took 5-10 seconds.

Tested 3.5 A2 this morning as https://issuetracker.google.com/issues/122028787 said there was maybe something in it.
Exact same performance issues with same timings.

From activity monitor during the slow analysis
350,0 <unidentified: JobScheduler FJ pool>

Is taking all the time and ressources

During the freeze for ctrl alt L, obviously Activity Monitor is frozen too :(

Thank you for the freeze dumps in comment #35 and #38. The stacks there show that it is mostly the Kotlin plugin that is at fault. The fix referenced above (comment #24) is about how the Android plugin interacts with the Kotlin plugin. So it is safe to say that this issue is primarily about Kotlin highlighting and you should only be seeing this in Kotlin files.

If anyone is seeing this outside of Kotlin files, please file a new bug and include thread dumps!

So no joint effort with JB and we poor users needs to start this again on JB side ? :)

Hmm, I don't think I said that. I was just pointing out what is there in those thread dumps!

Hum OK sorry I'm not native English, it sounded a little like that, thanks for clarifying.

Is there anything more we can provide?

Should we also be filing a bug with Jetbrains then?

If you see the same issue in IntelliJ on a non-Android project, then you're certainly welcome to file a bug with them.
However, we will be digging deeper ourselves, and working with JetBrains as needed.

I logged some thread dumps using jstack while opening different kind of files. I hope it helps to shed some light on the issue

Some more logs while opening a kotlin test file

Re: comment #46 and comment #47, which version of Studio is this from?

(Notes: All the traces still point to AndroidKotlinResolveScopeEnlarger,)

We thing the big regression from 3.2 should be fixed now in 3.3.1. This doesn't mean we're "done" with highlighting performance (or editor in general) of course. Please let us know if you can see 3.3.1 being noticeably slower than 3.2 (ideally using the same version of the Kotlin plugin).

It's still slower than 3.2 but it seems the 20+ second freeze with ctrl alt L and removing import is now more in the 4/5 second range, still frustrating but less time to break my keyboard :p

I guess it have something more than 3.4 B 3? Will this be in 3.4 B 4? Will you need more dumps when 3.4 B4 is out?

Dumps from 3.3.1 will also be useful.

Hi, original reporter here. Performance has improved on 3.3.1, thanks!

Find attached more dumps and logs

I think this issue is also affecting 3.5 Canary 3 which I'm using (and possibly 3.4 beta 3). The IDE is just extremely slow on my MacBook Air (8GB of RAM, 775Mbps SSD, Intel Core i5).

So tested 3.4B4 and there's still the 20+ second freeze for ctrl alt l + removing an import. And speed is clearly still not that great :(

Won't be able to provide dumps before next week, but please tell us what more you needs to narrow the issue, a 20 sec freeze on high end computer must not be as hard to spot as the other speed issues that can be a sum of small things.

Some notes:
- I'm unfortunately having trouble reproducing the ctrl alt l (reformat code) scenario. If I try that with 3.4B4 on a 1000-line Kotlin file in https://github.com/google/iosched then it takes ~1 second for me. This is using a mac laptop.
- If "removing an import" refers to the "optimize imports" action, then that too takes ~1 second for me. If it means "remove some imports and wait until syntax highlighting finishes" then that takes ~6-8 seconds, but in that case the UI is responsive the whole time. I see similar performance when using vanilla IntelliJ too.

So, more digging is needed. For those that want to help, there are a few options:
(1) If you have an open source project that exhibits these freezes, I would be very happy to take a look at it if you can give specific repro steps.
(2) You can provide additional thread dumps, along with precise info on which version of Studio and the Kotlin plugin you are using.
(3) You can provide a CPU sampling snapshot recorded while the freeze is taking place. We tend to use YourKit for this, but other profilers such as VisualVM should be fine too. This would give us a lot more information than thread dumps, so would be tremendously helpful.

@comment#55
"Using a mac laptop". We don't all have the latest MacBook Pro with 16-32GB
or RAM and an Intel Core i7 CPU. Test with a 4-8GB of RAM MacBook Air with
an Intel Core i5 CPU from 2013 (or older) please. I know you have plenty at
Google.
Also, please test on a big project with multiple projects, like this one:
https://github.com/LouisCAD/Splitties
On Sat, Feb 16, 2019 at 1:01 AM <buganizer-system@google.com> wrote:

Largest file found in iosched is 900 lines and strangely I can't reproduce either in it :(

Since yourKit seems paid, I can use VisualVM next week to try to advance, because each time there's an import removed when doing ctrl alt l (that I now do by instinct) and there's a 20 sec freeze I want to smash everything in the room :)

But I'll need more precise information about what / how to get the needed information, what settings, what duration? (Maybe a full 30 sec dump is too much data to analyse and you'd prefer multiple small duration dumps?)

comment#57 It's actually best to send one CPU sampling snapshot covering the whole freeze duration.

Here's what I recommend for creating a snapshot with VisualVM:
(1) Attach to AndroidStudio and go to the 'Sampler' tab.
(2) Click the 'Settings' checkbox to make sure all packages are profiled. The default 100ms sampling frequency should be fine.
(3) Click on the 'CPU' button to start sampling, just before triggering the freeze with Ctrl Alt L. Then click 'Stop' when the freeze ends.
(4) Click the 'Snapshot' button, then click the save icon and select 'Export Snapshot Data'. Then attach that file here.

Thank you!

Here are 3 snapshots + a thread dump.

The first freeze is in a 847 lines files in a medium module the second in a 1905 lines files in a small module (I know this is too much but I have no yet refactored this old part of the app :p)

Strangely the second freeze is faster than the first and today can't reach the 20 sec freeze.

Freeze 3 is in a 780 line file in a third module. (The largest module)

All modules are from the same application.

Always same repro steps.
Go to a function use auto completion to add Notification.AUDIO_ATTRIBUTES_DEFAULT that auto add the Notification import.
Remove the line.
Press control alt l to have the import removed. AS freeze for random duration up to 20 seconds on a very fast machine.

Anything in those files? Needs more things?

Hum :(

I'll continue to talk maybe there's still someone :p

AS 3.5B5 still the freeze + something that seems new and happens randomly but relatively frequently.

A large project opened without any file opened, no devices connected, no emulator running, yet activity monitor shows:

 93,8  Plugin Android Support: com.android.ddmlib

1 core at 100% cpu on ddmlib non stop.

For the ddmlib issue (comment #61), would you mind filing a separate bug and including a thread dump taken when you see that please?

#62 https://issuetracker.google.com/issues/126165767

Any way to know if anything else is needed for the lock on ctrl alt l. 3.4 RC is nearly out and 3.5 Beta probably starting next week would be nice to not keep that until 3.6.

@Tolriq thank you for the CPU profiles, those are extremely helpful. And apologies for the delays.

Good news is that I did find a serious bottleneck accounting for at least 40% of the UI freeze (possibly more, depending on when exactly the profile was captured). Quick summary: it turns out that sun.management.ThreadImpl.getThreadTotalCpuTime() is extremely slow compared to System.nanoTime(), and this was being used to measure the performance of some frequently called methods in the IntelliJ platform. The fix should make it into 3.4 RC1.

If you happen to try 3.4 RC1, let me know how it goes. In the meantime, I'll still be digging further.

By the way, the 40% number refers to freeze1.nps
For freeze3.nps, the same bottleneck is responsible for 75% of the time on the UI thread.

So can confirm RC01 is way better now the freeze on ctrl alt l are less frequent and for the moment at max 2 seconds. Thanks.

Still hope for more speed improvements for 3.5 3.6 as overall Kotlin is still slower than previously :(

@Tolriq thanks for the update!

We'll be continuing to work on overall performance.
In the meantime, if you come across specific situations where editor performance degrades significantly, I'm always happy to look through additional CPU profiles.

The ctrl alt l still freeze at some point but not all the time and for way lower duration, but I've restarted AS many times today.

Will take a couple of hours early next week to gather more profiles.

So it seems I actually spoke too soon :( I can still trigger long freeze, so it's probably also tied to the time AS is opened without a restart.

Here's 4 CPU snapshots.
01 is a small freeze in a small module after ctrl alt l to remove an import
02 is a very long freeze in the main module + wait until the full analysis is made  after ctrl alt l to remove an import
03 is very long syntax coloring + analysis when opening a large file
04 is a very long analysis to detect an erroneous line added on purpose

As a reminder those are captured on a Windows 10 computer with all patches, i7 6850K (12 cores) 64GB ram, high end m2 SSD (960Pro). It's already hard to work with those numbers so can't imagine with a normal spec computer / laptop.

Adding a small note, ctrl alt l freeze whenever it needs to touch the imports. Not only removing but changing order trigger the same issue.

Those CPU profiles are very helpful, thank you!

I confirmed that getThreadTotalCpuTime() no longer shows up, but there appear to be major performance bottlenecks in the Kotlin plugin. I'm still investigating, here is a summary so far:

KotlinImportOptimizer can take over 20s CPU time in some cases, all on the UI thread
    Includes 13s spent in KotlinScriptDependenciesClassFinder.findClass().
    @Tolriq, can you confirm that you have .kts files in your project?
    Note that I found a bug reported to JetBrains that may be related:
        https://youtrack.jetbrains.com/issue/KT-29644

Syntax highlighting can take over 20s CPU time and over 100s(!) wall clock thread time across 10+ threads
    Much of the 100s is spent locked inside Kotlin's LockBasedLazyResolveStorageManager$LockProtectedContext.get()
    Suggests non-parallelized / non-parallelizable work, or lock contention

Note: I see very little Android-related code showing up in the profiles.

See also this attached text file with more in-depth notes on the individual profiles.

Also, for reference, here are some additional related bugs already reported to JetBrains:
- https://youtrack.jetbrains.com/issue/KT-28564 (Kotlin slow in IntelliJ)
- https://youtrack.jetbrains.com/issue/KT-30018 (Kotlin slow in Android Studio)
- https://youtrack.jetbrains.com/issue/IDEA-206649 (Kotlin auto-import freeze)
- https://youtrack.jetbrains.com/issue/IDEA-205486 (freezes while editing .kts files)

gh...@google.com

I have been experiencing similar slowness on a powerful machine (64GB of ram) and I'm now convinced it's slow because I'm using a .kts file in my buildSrc module. I followed this article to implement buildSrc https://handstandsam.com/2018/02/11/kotlin-buildsrc-for-better-gradle-dependency-management/

At a certain point a few months ago I think build.gradle files stopped auto completing my dependencies from the buildSrc (I also can't cmd + click into the dependencies and drill to the declaration in buildSrc. This used to work as well). This was a main reason that I used buildSrc so I could auto complete and use a single version in multiple modules.

Anyway. I bet this is a leading cause of some of this slowdown.

Yes I have migrated all my build scripts to kts and have a kotlin buildsrc. But have no issue when editing them and auto complete / ctrl click works ok.

to...@gmail.com I use kotlin buildSrc, but I didn't actually migrate my build.gradle files to kotlin/kts files.

Maybe if I did that then auto complete and such would work BUT I did hear from the AMA that the android tools team did recently, was that kotlin build files aren't really ready for primetime yet. But I don't have any actual build.gradle files written in kotlin, it's just that I have my Dependencies declared in a kotlin file in buildSrc and I have had that for months.

Don't seems to be any Jetbrains reaction on the linked YT issues :(

Is there some other internal discussions about this issue or is it time to think about loosing a few hours reverting all to groovy and remove buildSrc?

We're in contact with JetBrains internally, though I think they're still in the investigation phase. Unfortunately I don't have an estimate for how long it will take to fix.

Notes: If you *did* revert back to groovy, I'm pretty sure the optimize-imports freezes would go away, but I'm less sure about the syntax highlighting slowdown you see.

Ugh, I do not want to move back to groovy and such. It was quite an effort to move over.

I'm confident you all will find track down the issue. I made the change to use buildSrc months ago and it really helped keep sanity in my modules and builds files. I'll keep holding my breath! =)

Notes: JetBrains has fixed the performance bottleneck in KotlinScriptDependenciesClassFinder at https://github.com/JetBrains/kotlin/commit/742ffb98ad34718c0ac94336ab808203bd008027, although I'm not certain which Kotlin plugin release it will land in (probably 1.3.40).
They're still looking into the other bottlenecks, including cases of slow syntax highlighting.

Sounds good if it's the freeze for ctrl alt l :)

Unfortunately yes it's tagged 1.3.40 only I doubt it will be cherry picked that far in 1.3.30 :( Let's pray for a 1.3.31.

@gh...@google.com

Who's in charge of kotlin plugin releases? Jetbrains I assume? And in that case, how do I update the plugin? Is this in AGP intrinsically, or is this the Kotlin plugin in the IDE, which means that it's not in version control (most likely) for anyone? I guess I just want to know, from a developer POV, how can I make sure I'm using the latest so I don't have this issue?

Comment #82, JetBrains manages Kotlin plugin releases. Each release of Android Studio comes bundled with a recent version of the Kotlin plugin, but you can upgrade to a new release at any time (in Android Studio, see Tools -> Kotlin -> Configure Kotlin Plugin Updates).
That version of the Kotlin plugin is unrelated to the kotlin-gradle-plugin version that you generally specify in a build.gradle file. I believe Lint warns you if that version does not match the Kotlin plugin version in the IDE, since such a mismatch could result in inconsistencies between IDE code analysis and Gradle builds.
And yes, this bug is about the Kotlin plugin in the IDE, *not* the kotlin-gradle-plugin.

Whoah nelly. Too many version numbers and plugins to keep straight here. Hah.

I will keep trying to refresh for an update. In the meantime, do you know if they have a release page, or an actual ticket number I can keep track of. The above github link was just to the code, but not a PR or Issue number.

I tried to dump threads with VirsualVM. Following #58 instruction. Not sure if I did it right.
I dumped two files for a kotlin file that has 2000 lines of code.
One is for slow reformatting, takes like 10 secs.
Second is for slow completion, takes like 3 secs.

Forgot to mention my AS version is 3.4.1.
VM options
-Xms256m
-Xmx8192m
-XX:ReservedCodeCacheSize=240m
-XX:+UseConcMarkSweepGC
-XX:SoftRefLRUPolicyMSPerMB=50
-Dsun.io.useCanonCaches=false
-Djava.net.preferIPv4Stack=true
-Djdk.http.auth.tunneling.disabledSchemes=""
-Djna.nosys=true
-Djna.boot.library.path=
-da

OS: Win10 64bit

PC:
16GB (4x 8GB) DDR4 2666 MHz HX426C15FBK2/16
Samsung 850 EVO 500GB 2.5" SATA III SSD MZ-75E500
Intel Core i7 6700K Quad Core LGA 1151 4.0 GHz Unlocked CPU Processor

We also are currently experiensing a **very** slow competion in XML layout editor on Studio 3.5 Beta 5. On Windows it takes 10-15 seconds for autocomplete to popup. On Linux it is about 3-5 seconds, which also makes it very hard to edit layout files, because every 3rd keystroke I type results in a completion attempt -> lag.

What can I do to help debug this? Will capturing VisualVM trace be enough?
Or is this a known issue? Maybe the same as #85.

Versions:
Android Studio 3.5.Beta5
AGP 3.5 rc05
Kotlin: 1.3.41

Another snapshot for slowing analysis. Took 7 secs to analysis after I made changes on the 2000 lines file to show the error line.

@zero.arst, your VisualVM snapshots show the majority of time spent in what appears to be a performance bug in kotlinx serialization. I found a JetBrains bug which appears to be similar, and I've added additional details there, including a picture of the relevant parts of your snapshot: https://youtrack.jetbrains.com/issue/KT-32346
(In short: kotlinx serialization support in the Kotlin plugin ends up making way too many File.exists() calls. It appears to only affect MPP projects.)

@dimsuz, yes, a VisualVM trace is often enough to find the cause. However, I believe your issue is a duplicate of https://issuetracker.google.com/133864394, which we are already actively working on.

Oh, good to know! And I have decided to report it as a separate issue today, I guess it now should be closed as a duplicate:

https://issuetracker.google.com/issues/136979922

Sad that this is marked obsolete, but I guess there are new bugs that we should file.

The title from 2018 is still very much what is happening to me "AS is slow, I can see the lines as they go from being uncolored and then highlighted"

Amazing that after 18 months, with 64GB of RAM, latest AGP, latest kotlin + plugin, AS 4.0 Beta 2... I still can't use my IDE as I once did with Java.

I guess it's up to Jetbrains to fix https://youtrack.jetbrains.com/issue/KT-32158