Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Poor performance of SourceDistributionProvider on the cold start #28986

Open
nskvortsov opened this issue Apr 26, 2024 · 4 comments
Open

Poor performance of SourceDistributionProvider on the cold start #28986

nskvortsov opened this issue Apr 26, 2024 · 4 comments
Assignees
Labels
a:performance-improvement Performance improvement potential in:kotlin-dsl
Milestone

Comments

@nskvortsov
Copy link
Contributor

Current Behavior

Execution of actions inside Cold Gradle Daemon in IDEA takes 6.6 seconds

Expected Behavior

Execution of actions inside Cold Gradle Daemon in IDEA takes 5 seconds

Context (optional)

Investigated log reload of a tine project on a Windows machine.

The telemetry shows that a lot of time is spent inside the KotlinDslScriptModelProvider

Attached snapshot shows that 1.7 seconds are spent by Gradle code in KotlinDslScriptsModelBuilder to resolve the readily available (downloaded and unpacked) sources.

This seems unnecessary.

OpenTelemetry: image

Zipped JFR: GradleDaemon_2024_04_26_200508.zip

Steps to Reproduce

Get the attached project, open and sync it in the IDEA.
Stop the running Gradle daemon.
Execute sync once again.

Gradle version

8.2

Build scan URL (optional)

No response

Your Environment (optional)

No response

@ov7a ov7a added in:kotlin-dsl 👋 team-triage Issues that need to be triaged by a specific team and removed to-triage labels May 7, 2024
@ov7a
Copy link
Member

ov7a commented May 7, 2024

This issue needs a decision from the team responsible for that area. They have been informed. Response time may vary.

@eskatos
Copy link
Member

eskatos commented May 16, 2024

The way the Gradle distro is turned into usable source directories for the IDE is by using two artifact transforms.
The first one unzips the distro, the second one selects the relevant directories from it.

These transforms are cached locally. Gradle needs to snapshot their inputs and outputs in order to have a cache hit.
The output of the first transform is the directory of the unpacked distribution.
The input to the second transform is the same.
The outputs of the second transform are all relevant source directories.
This is a lot of files and would explain why it takes a while on Windows' poor i/o.

Could you please provide a build scan of your observation?
They now contain insights on transforms that could help confirm that theory.

In any case we should rework this transformation pipeline. Merging the two transforms should greatly reduce the overhead.

@eskatos eskatos added a:performance-improvement Performance improvement potential and removed a:bug 👋 team-triage Issues that need to be triaged by a specific team labels May 16, 2024
@eskatos eskatos added this to the 8.9 RC1 milestone May 16, 2024
@eskatos eskatos self-assigned this May 16, 2024
@nskvortsov
Copy link
Contributor Author

This is the part of JFR in question. Please note this is the Wall time (not CPU)
image

I will do the build scan shortly

@nskvortsov
Copy link
Contributor Author

Unfortunately, I am unable to do the build scan.
I need to configure the ToS agreement in a build script (as sync is non-interactive).

But the develocity plugin fails with the following error (tried Gradle 8.2, 8.4 and 8.7):

Build file 'C:\Users\Nikita.Skvortsov\tmp\untitled\build.gradle.kts' line: 1

An exception occurred applying plugin request [id: 'com.gradle.develocity', version: '3.17.3']
> Failed to apply plugin class 'com.gradle.scan.plugin.BuildScanPlugin'.
   > The build scan plugin is not compatible with Gradle 6.0 and later.
     Please use the Develocity plugin instead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
a:performance-improvement Performance improvement potential in:kotlin-dsl
Projects
None yet
Development

No branches or pull requests

3 participants