Skip to content

Improvement: Add instrumentation to allow warning on files that take long to format #989

New issue

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

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

Already on GitHub? # to your account

Open
wants to merge 5 commits into
base: develop
Choose a base branch
from

Conversation

MTelling
Copy link

Before this PR

We have noticed the formatter becomes really slow on functions that nest a lot, causing some files to take +10 seconds to format.
A simple refactor can often fix these issues but it can be hard to identify and enforce that files are kept in a shape that formatter formats quickly.

This PR adds instrumentation to file formatting and, if enabled, prints errors to the console for files that exceed the specified threshold.

After this PR

==COMMIT_MSG==
Add instrumentation to allow warning on files that take long to format
==COMMIT_MSG==

Possible downsides?

I'd rather fix the formatter here but that might take a lot more time and in places where we've seen issues, the code could use a refactor anyway (deeply nested code is not very pretty).

@@ -45,6 +45,7 @@ final class CommandLineOptions {
private final Optional<String> assumeFilename;
private final boolean reflowLongStrings;
private final boolean outputReplacements;
private final Optional<Long> warnOnExpensiveFileDurationMillis;
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would probably long term want to be able to set a failIfDurationExceeded option as well. Ideas for if this flag should be altered or if it's just another config?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just another config, imo

Morten Telling added 3 commits January 22, 2024 19:09
Copy link
Contributor

@ash211 ash211 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would be helpful for a project I'm working on where we are spending nearly as much time on spotless as we are on compilation!

  • 37m 15.661s on Spotless
  • 45m 5.492s on Compile

Comment on lines +22 to +24
long start = System.currentTimeMillis();
String result = delegate.call();
Duration duration = Duration.ofMillis(System.currentTimeMillis() - start);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if you have Guava on the classpath already, use Stopwatch?

@@ -185,6 +188,11 @@ boolean outputReplacements() {
return outputReplacements;
}

/** Returns the number of millis to allow processing of a single file to take before warning. */
Optional<Long> warnOnExpensiveFileDurationMillis() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can this be Optional<Duration> ?

@@ -45,6 +45,7 @@ final class CommandLineOptions {
private final Optional<String> assumeFilename;
private final boolean reflowLongStrings;
private final boolean outputReplacements;
private final Optional<Long> warnOnExpensiveFileDurationMillis;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just another config, imo

if (parameters.warnOnExpensiveFileDurationMillis().isPresent()
&& fileResult.duration().toMillis()
> parameters.warnOnExpensiveFileDurationMillis().get()) {
errWriter.println(path + ": took " + fileResult.duration().toMillis() + "ms to format, "
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: put WARN in this message, so it shows up when people Cmd+F for warnings (which log but do not fail builds)

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants