Gradle build is slow again

[petervdonovan]

In recent days (I am not sure when) I started finding cli:lfc:run taking 45 seconds to a minute. IIRC this was fairly fast after #1779 was merged. I ran the task with the --scan flag and found this:

The following is strange because I do not see how this triggers the spotlessLinguaFranca task, and because when I ran cli:lfc:run with the --dry-run option, I did not see any Spotless tasks.

The following is strange because I did not edit any Kotlin files:

Configuration and Kotlin compilation appear to account for the most the time spent in this case, and much more time is spent in configuration than in anything else.

[cmnrd]

There might still be some problems in the gradle configurations. Something I still do not fully understand is when gradle actually evaluates tasks. I am also not sure what "created during configuration" means. As war as I understand, gradle always executes the full configuration, collects all tasks and configures them, but does not execute the tasks themselves. Thus, I would assume that "created during configuration" just means the task was discovered and configured, but not executed. What is still mysterious to me, is which parts of a task are actually processed during configuration and which later during execution. Interpreting the numbers you show, it looks like some task(s) have quite a high overhead during configuration.

We can try two things:

• Identify the task(s) that cause a long configuration time and try to fix them.
• Avoid the task configuration in the first place. Gradle provides a bunch of mechanisms for defining and referencing tasks without configuring them. Tasks are only configured when they are actually loaded (see https://docs.gradle.org/current/userguide/task_configuration_avoidance.html). We don't do this consequently at the moment.

I think the ideal solution would be to do both.

[petervdonovan]

Update: I just now realized that part of the reason why "configuring" took so long is that I had a very large number of untracked files in various src-gen and fed-gen directories. This might help us figure out what the problem is, and in any case it leads to an easy workaround (delete any files that are not needed).

[cmnrd]

Interesting, except for the src-gen directory produced by xtext, we explicitly ignore all src-gen and fed-gen directories. But perhaps this ignoring is what makes Gradle slow. We have this in build.gradle:

spotless {
    format 'misc', {
        target rootProject.fileTree(rootProject.rootDir) {
            include '**/*.gradle', '**/*.md', '.gitignore', '**/*.yml', '**/*.sh', '**/*.psi'
            exclude '**/reactor-cpp/**', '**/reactor-c/**', '**/reactor-rs/**', '**/lf-python-support/**',
                    '**/src-gen/**', '**/fed-gen/**', '**/test-gen/**', '**/build/**',
                    'test/*/include', 'test/*/bin/', 'test/*/share', 'test/*/lib'
        }

        // define the steps to apply to those files
        trimTrailingWhitespace()
        indentWithSpaces(2) // or spaces. Takes an integer argument if you don't like 4
        endWithNewline()
    }

    format 'linguaFranca', {
        addStep(LfFormatStep.create())
        target 'test/*/src/**/*.lf' // you have to set the target manually
        targetExclude 'test/**/failing/**'
    }
}

Perhaps the required pattern matching on a large file tree is what slows gradle down.

[lhstrh]

Seems like we could easily remove a bunch of globstars and substitute them with relative paths...