-
Notifications
You must be signed in to change notification settings - Fork 56
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
base: develop
Are you sure you want to change the base?
Conversation
@@ -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; |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just another config, imo
…r/palantir-java-format into mt/add-instrumentation-for-files
There was a problem hiding this 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
long start = System.currentTimeMillis(); | ||
String result = delegate.call(); | ||
Duration duration = Duration.ofMillis(System.currentTimeMillis() - start); |
There was a problem hiding this comment.
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() { |
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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, " |
There was a problem hiding this comment.
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)
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).