format: Slow performance for --include with single file

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?

Using the --folder option and formatting only whitespace should be much faster than formatting based on a project or sln file.

I’m certainly not happy with the level of performance we have here either. I know it is unsatisfying to hear that after years since this issue was filed. It is difficult to carve out time for this in addition to my ordinary responsibilities.

We do care and it does help to have people let us know that this is impacting them. I apologize that this is the state dotnet-format is in currently.

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.

@jmarolf @JoeRobich I would like to urge you guys once again to give this issue a bit more attention.

This is what happens when you try to format ~5 C# files using dotnet format:

34 seconds! And remember that this is typical for dotnet format actually, it’s not a one time thing. This is just unacceptable. There must be something horribly wrong with the implementation of this tool for it to yield results like this. It’s almost unusable.

Please respond. Thank you.

Any updates on this? Is there any workaround?

@RikkiGibson I think the formatter should have a version which does not requires that msbuild loads and scans the whole solution/project. Especially the case when a single file is going to be formatted.

I have a PR that should help with single file includes a bit: https://github.com/dotnet/format/pull/1485

@seriouz I use Ubuntu and the performance is horrendous.

From my personal experience within the team, it is basically unusable (and I am not talking about thousand of files, just a precommit hook for staged files) on Windows machines, but the performance is acceptable on the M1/M2 chips from Apple.

I would have liked to use dotnet format for a pre-commit hook, but it is horribly slow. I am used to work with the GNU Toolchain, make, gcc, gtags etc. Microsoft tools are all significantly slower and sometimes slower by an order of magnitude, but

dotnet format --verify-nochanges SingleFile.cs

is like three orders of magnitude slower than using Artistic Style or Clang for formatting. Come on Microsoft, it is 2023

Any updates on that? It takes more than 30s to do dotnet format solution.sln --include file.cs for me.

~15s for

All projects are up-to-date for restore.
  Project Api is using configuration from ...
Complete in 14412ms.

~15s for

Running formatters.
  Running Code Style analysis.
  Determining diagnostics...
  Running 1 analyzers on ...
  Complete in 15566ms.

And the worst thing is that I have to check formatting for 6 such solutions in the same repo 😦

It is still slow as hell. 8 seconds for one file and this is without -s and -a.
go fmt runs in under a second for me.

yeah. I’ll need to look here but I think a reasonable place to start at is that we should be able to get single file formats under 500ms

Great, thanks.

Just for a little more context, I’m playing around with integrating with https://pre-commit.com/. That passes the list of files to check as command-line arguments (usually just the files being committed, unless you tell it to run on all files).

No, I’ll likely use your project as the basis for some perf validation.

Yep this should be fast. The second we spend discovering files is unnecessary. that at least gets us to 500ms