runIdeTask Takes 20-40 Seconds on Windows 11 Due to IDE Instance Recreation

[jiec-msft]

I've encountered a performance issue where the runIdetask consistently takes 20-40 seconds to start on Windows 11.

After investigation, I found that the task appears to always execute the full IDE creation path in IdesManagerService.resolve():

fun resolve(platformPath: Path) = ides.computeIfAbsent(platformPath.safePathString) {
    log.info("Creating new IDE instance from: $platformPath")
    createIde {
        missingLayoutFileMode = SKIP_SILENTLY
        path = platformPath
    }
}

Further tracing suggests this calls into the With a further tracing, seems calling into https://github.com/JetBrains/intellij-plugin-verifier/blob/0544ae86d462311896aca9a50d6bd4106d0a8634/intellij-plugin-structure/structure-ide/src/main/java/com/jetbrains/plugin/structure/ide/DispatchingIdeManager.kt#L22C1-L30C4. However, the current logging (or possibly my log level configuration) doesn't provide sufficient details to pinpoint the exact bottleneck.

Partial logs for reference:

runIde-partial.log

Questions:

1. IDE Instance Reuse: Is it possible to cache and reuse the created IDE instance when only plugin code changes, rather than recreating it each time?
2. Windows Optimization: Are there any known optimizations or configuration changes that could accelerate this process specifically on Windows?

Environment:

• OS: Windows 11
• Task: runIde
• Observed delay: 20-40 seconds per run
• intellij-platform-gradle-plugin: 2.5.0

I'd appreciate any guidance on improving the startup performance. Thank you for your time and consideration!

[jonathanlermitage]

Can you share a sample project and, ideally, a build scan?
I also face performance problems and bugs on Windows (10), but your issue seems different. There is no reason to recreate the IDE instance, so I guess there is something wrong in your build.gradle or, as suggested on Discourse, you're using an outdated version of the intellij platform gradle plugin.

[hsz]

The createIde function comes from the Plugin Verifier library. It is a known issue that PV on Windows works way slower due to File System operations. See #1905

[jonathanlermitage]

The createIde function comes from the Plugin Verifier library. It is a known issue that PV on Windows works way slower due to File System operations. See #1905

Plugin version 2.1.0 did not have this performance problem. So, I guess we can expect a fix.
#1905 has been opened 9 months ago... 😢

[hsz]

The 2.1.0 didn't rely on Plugin Verifier when resolving dependencies.

[jonathanlermitage]

Yeah, so the platform plugin was able to do this faster than the plugin verifier.

[hsz]

The assumption is incorrect. The Gradle plugin’s classpath resolution had significant gaps and could not keep pace with changes in the IntelliJ Platform, so duplicating the logic in two places is futile.
Historically, the Gradle plugin didn’t inspect bundled plugins/modules when computing the dependency graph — it simply included all jars indiscriminately. As Remote Development evolved, that approach caused conflicts (the same classes ended up in both backend and frontend jars) and ultimately broke builds starting with 2025.1+. Moreover, even if we replicate the correct logic from PV into IJPGP, Windows-specific filesystem issues will still occur.

[jonathanlermitage]

Thx for the details 👍
But, can we expect a fix? Plugin development on Windows is so painful, and #1905 seems abandoned.

[hsz]

Issue to track: MP-7927

[jonathanlermitage]

It seems to be private

[hsz]

Fixed.