0.41.0 Performance decrease

[greggiacovelli]

Expected Behavior

When updating between versions, I expected comparable performance.

Observed Behavior

Upgrading from 0.40.0 to 0.41.0 decreases performance considerably. I noticed this from using a precommit hook and the time to commit even a file without any formatting issues, went up considerably. When using Debug flags on 0.41.0 the print outs stop at:
[DEBUG] Initializing "plain" reporter with {verbose=true, color=false, color_name=DARK_GRAY}
where it takes the majority of the observed lag (~30+ seconds)

Steps to Reproduce

time java -jar ktlint0.40.0.jar --verbose --relative . --format -- AnyFile.kt 
java -jar ktlint0.40.0.jar --verbose 1.41s user 0.24s system 150% cpu 1.093 total

Now with the same file in the same state:

time java -jar ktlint0.41.0.jar --verbose --relative . --format -- AnyFile.kt 
java -jar ktlint0.41.0.jar --verbose 5.70s user 21.05s system 73% cpu 36.156 total

lsof of the process while in this state shows it trying to traverse the entire directory structure, whereas before this would short circuit only to the files on the command line. I understand the glob logic changed, however something seems up, even if it eventually gets to the right file, it seems to take a rather long time to find it.

Your Environment

• Version of ktlint used: 0.41.0, 0.40.0
• Name and version (or code for custom task) of integration used (Gradle plugin, Maven plugin, command line, custom Gradle task): command line/java openjdk version "11.0.10" 2021-01-19
• Version of Gradle used (if applicable): N/A
• Operating System and version: OSX 11.2.3
• Link to your project (if it's a public repository):

[shashachu]

@greggiacovelli would you be able to test with the latest SNAPSHOT and see if this is resolved? We merged #1144 which may help.

[greggiacovelli]

@shashachu Nice! Simple anecdotal test of changing a single file in the repo with a bunch of spaces and imports reordered. And then invoking ktlint on just the file, resulted in 1 sec time until output

1. vim repo/File.kt (re-order imports)
2. time java -jar ktlint-0.42.0-20210628.180722-18-all.jar repo/File.kt

Results in:

repo/File.kt:7:1: Imports must be ordered in lexicographic order without any empty lines in-between
repo/File.kt:28:1: Unexpected indentation (8) (should be 4)
repo/File.kt:47:1: Unexpected indentation (8) (should be 4)
java -jar ktlint-0.42.0-20210628.180722-18-all.jar  1.21s user 0.23s system 144% cpu 1.000 total

vs with no file arguments, evaluates the entire codebase (which is expected)

1. time java -jar ktlint-0.42.0-20210628.180722-18-all.jar

Results in:

... all files attributed
java -jar ktlint-0.42.0-20210628.180722-18-all.jar  181.80s user 26.65s system 354% cpu 58.827 total

Seems fixed to me

[shashachu]

@greggiacovelli great. thanks so much for confirming, and thank you to @rciovati for the fix!

[shashachu]

Will be released in 0.42.0 (ETA ~1-2 weeks.)

[francescocervone]

@shashachu It's not fixed to me, the issue should be reopened.

Version 0.40.0

2,34s user 0,22s system 141% cpu 1,814 total

Version 0.41.0

4,51s user 16,13s system 62% cpu 32,887 total

Version 0.42.0

4,26s user 15,92s system 59% cpu 33,729 total

Version 0.43.2

4,41s user 16,46s system 61% cpu 33,779 total

Tested with the same two files.

It's painful if you have a pre-commit hook.

Environment:

• openjdk64-11.0.10
• macOS 11.5.2

[greggiacovelli]

It's definitely slower but I think the 30 seconds from the past is fixed. I have found it required to either specify all files that need to be formatted/checked via pre-commit or when using it on a code base to prune any stale directories as this adds to the issue. Cpu is not very high so yeah it seems like it's traversing files in your case

[francescocervone]

it seems like it's traversing files in your case

🤦 You are right!
The default pre-commit hook which is installed via ktlint installGitPreCommitHook passes the current directory as first argument, therefore, even if only changed files are piped, that . at the end of the line is making ktlint checking all files.

This is the pre-commit hook installed by ktlint:

#!/bin/sh
# https://github.com/shyiko/ktlint pre-commit hook
git diff --name-only --cached --relative | grep '\.kt[s"]\?$' | xargs ktlint --relative .
if [ $? -ne 0 ]; then exit 1; fi

Am I wrong?

[greggiacovelli]

Yeah I have been using pre-commit to manage my pre commit hooks. It searches the git index and can pass the exec path only the files in question. https://github.com/macisamuele/language-formatters-pre-commit-hooks has a collection of hooks for this system that works really well

[francescocervone]

I was thinking about this.

Even if my pre-commit hook was traversing all files, there is a tremendous performance decrease from 0.40.0 to 0.41.0, 0.42.0, 0.43.2. I haven't changed the pre-commit hook while performing my tests, which means something has clearly changed in ktlint affecting performances. I ran my tests under the same conditions, just switching ktlint release.

Sure, it doesn't make any sense to traverse all files if you just want to check changed files, but 0.40.0 was way faster than 0.41/0.42/0.43 in doing so.

[greggiacovelli]

Ah sorry my sh knowledge is not great. Actually after looking over your hook a bit more, I think the intention was for the current directory to be passed to the --relative switch so that all paths are indicated as relative to the current directory. So if that is correct, then yes there should be no overhead in the whole directory.

However that might not function the same after the changes in 0.41.0 as if I recall the way paths were resolved had been re-implemented. The resulting hook may have been updated too to account for the new behaviors. However it's possible it may not have been updated too

So after re-installing the hook, are the same symptoms present?

[francescocervone]

I think the intention was for the current directory to be passed to the --relative switch

I don't think that the current directory is an argument for --relative, looking at its documentation

--relative   Print files relative to the working directory (e.g. dir/file.kt instead of /home/user/project/dir/file.kt)

The resulting hook may have been updated

Hooks were never updated after 0.40.0. The one I pasted here is the same from 0.40 to 0.43.

[greggiacovelli]

I think then we found the issue. If after making the change (removing the .), do it work better? Can you test and then submit a patch if necessary? Otherwise might be best to file another issue focused on the git hook

[francescocervone]

Yes, it works. Performance is comparable to the one observed in 0.40.0.
I will submit a patch soon.

[greggiacovelli]

@francescocervone You may need to create a new issue to address what you are seeing as it is not 100% related to this issue.

https://github.com/pinterest/ktlint/blob/3866e09dd36f5559f3a7c9f8c1d080f3211d095a/CONTRIBUTING.md