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

Some performance improvements stubs #1386

Closed

Conversation

jrudolph
Copy link
Contributor

@jrudolph jrudolph commented Mar 14, 2019

These are more ideas than finished solutions. I'll probably don't have time to work further on these.

See #1385

I only ran this one benchmark but there it's a ~ 20% improvement.

Before:

Micro.ExtraLarge.scalafmt  avgt   25  2177.608 ± 99.453  ms/op

After:

Micro.ExtraLarge.scalafmt  avgt   25  1756.014 ± 64.865  ms/op

tanishiking and others added 30 commits February 8, 2019 01:28
This PR enable scalafmt-cli to automatically fetch a scalafmt of which
version matches the `version` setting in `.scalafmt.conf`.
This change will help syncing the version of scalafmt among
build tool integrations, editor integration, and scalafmt-cli.

See: scalameta#1318
     scalameta#1346
1) Moved everything related to downloading process to
ScalafmtDynamicDownloader
2) Created errors ADT for all currently reported error types
3) Split format method to two: one returns machine readable error from
from errors ADT hierarchy, another one handles the error and reports
user-readable message to provided reporter
1) move invoke and invokeAs to implicit ops class methods
2) add invokeStatic implicit method for classes
3) rearrange classes and methods loaded from classLoader
4) unified field names for loaded classes
- resolve error during download
- unknown exception during download: network errors, possible NPE etc...
- corrupted classpath exception: for cases when reflection operations
inside ScalafmtReflect cause unhandled exceptions
- ScalafmtDynamic is now responsible for both config caching and
scalafmt caching
- ScalafmtDynamic is now responsible for checking for checking whether
source file matches config includes/excludes filter
- ScalafmtReflect now simply represents a wrapper around Scalafmt
instance of a specific version, providing us an interface that
encapsulates all reflection stuff
- Load a scalafmt jar using scalafmt-dynamic only when
  scalafmt-cli's version doesn't match specified `version` setting.
  If the version matches, scalafmt-cli formats codes using
  pre-resolved scalafmt to save the overhead for resolving scalafmt
  jar on runnning.
- Create tempFile that contains configration string specified by
  `--config-str` option for passing configration to scalafmt-dynamic.
- Test for the behavior if .scalafmt.conf is missing.
- Test for the behavior if `version` setting is missing.
Make scalafmt-cli to use scalafmt-dynamic module instead of depending on specific version of scalafmt-core.
…integrate-with-intellij

1344 api changes to integrate with intellij
…fmt-org

Update website for sbt-scalafmt 2.0.0-RC5
```scala
// Before
for (a <- as)
yield
  Future {
    // ...
  }
// After
for (a <- as)
yield Future {
  // ...
}
```

It's possible to get the old behavior with `newlines.avoidAfterYield = false`.

While working on this change, I observed that
`style.indentYieldKeyword=true` (default) has undesirable (and
unexpected) behavior for val definitions.
```scala
// Before
val x = for (a <- as)
  yield a
// After
val x =
  for (a <- as)
    yield a
```
The new behavior is more consistent with how we handle other val
definition bodies. By forcing a line break before `for`, we make
it easier to associate the `for` keyword with its accompanying `yield`.
hehe seems the scalafmt repo uses and old scalafmt version that doesn't
automatically remove trailing commas. Will upgrade in separate PR.
Avoid newlines after yield keyword.
Copy link
Member

@olafurpg olafurpg left a comment

Choose a reason for hiding this comment

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

Wow, thank you very much for this contribution! I am impressed that the speedups are so significant with such small changes.

I am curious if the improvements here compose with the optimizations in #1345 That PR is ready to merge but since it does deep internal changes I want to run a few manual checks on large codebases first.

The CI failures look legitimate and caused by the change from Input.VirtualFile, otherwise LGTM 👍

@olafurpg
Copy link
Member

Superseded by #1564

@olafurpg olafurpg closed this Nov 27, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants