Slow performance for --include with single file

Hi, I’m just experimenting with dotnet-format for the first time. I noticed that running it on a single file has more overhead than I would expect.

# Run on 223 files 
$ git ls-files | grep .cs$  > all_cs.txt
$ dotnet format --folder --include @all_cs.txt
  Formatting code files in workspace '/xyz/ml-agents'.
  ...
  Format complete in 2297ms.

# Run on 1 file
$ dotnet format --folder --include com.unity.ml-agents/Tests/Editor/MultinomialTest.cs
  Formatting code files in workspace '/xyz/ml-agents'.
  Format complete in 1325ms.

Is that expected? It’s not horrible, but it would be mildly annoying to run incrementally on git commits.

Platform/version information: MacOS 10.14.6

$ dotnet --version
3.1.401
$ dotnet-format --version
4.1.131201+82a5527cd93d66bffc885c0bb901499f5981db35

[aradalvand]

Same here. This is the single biggest problem dotnet format suffers from. It’s simply unacceptable that it takes multiple seconds to format a single file. Formatters built into Visual Studio or the OmniSharp extension for VS Code typically take under 500 milliseconds to format a single small-to-medium-sized file.

Similar tools in other ecosystems such as go fmt or prettier are much, much more performant as well. This issue needs to be given higher priority, I’d argue.

@jmarolf @JoeRobich Sorry to tag you guys, but just wanted to get some updates on this. Have you guys managed to identify the root cause of this yet?

[codec-abc]

Is this issue actively working on? I am under the impression that dotnet format is somewhat slow which make make it annoying to run locally before committing.