IssueTracker

Which OS are you using?  By Android Studio beta 2, do you mean Android Studio 3.1 beta 2?

I have a couple of ideas in mind.  It may be that LLDB (which is what Android Studio is using for native debugging) is slow with that many modules, or that logic that is trying to show loading progress is actually slowing us down significantly in this case.  FWIW, LLDB does have caching, but it's possible that it is malfunctioning here of course.

Pile of questions to help me figure this out:
How are your modules built?  Are you intending to debug the code in all of those modules?  Do they all have debug info?  Are they stripped before packaging into the APK (if Android Studio is doing the packaging, my understanding it that it always strips)?

Do your modules have build-id? (On linux, you can check with 'readelf -n <path_to_library>' and look for .note.gnu.build-id, don't know how easy it is to get an equivalent tool on mac or windows).  LLDB uses that for caching, but has a fallback that may be more expensive, and testing of that many modules is probably non-existent.

How big is your APK (and total size of native libraries, I guess)?

We see this on MacOS High Sierra and on Android Studio 3.1 RC2
The modules (about 250) are built with Gradle except for the native library which is built with CMake using the ndk-toolchain but outside of Android Studio.
The unstripped version of the native library is about 1Gb

readelf -n on the native library gives me:

Displaying notes found at file offset 0x000001cc with length 0x00000024:
  Owner                 Data size       Description
  GNU                  0x00000014       NT_GNU_BUILD_ID (unique build ID bitstring)
    Build ID: 58ec6761213b1afe432867719a4a2089de3c2a66

Andrew: I don't think this is lldb-related. Looking at the visitNativeLibraries function, it certainly has room for pathological behavior in projects with large number of modules and complex dependencies. I think we should rewrite it to use some BFS/DFS algorithm to make sure it visits each module only once.

Ah, I didn't see the attachment.  It's a bit surprising that that code is causing the issue, because it's pretty old.  It's possible that projects with that many modules are rare, and even if they have many modules, the dependencies need to be structured such that there is a lot of shared (large) subtrees to get noticeable performance impact.  Anyway, I've fixed it by keeping track of which modules we've already visited.  The fix should be released next week or the week after (3.2 Canary 9 or 10).