rustfmt is slower with dprint-plugin-exec

[aminya]

Given the recent versions, I am forced to use dprint-plugin-exec for formatting the rust files. However, I have noticed ~3 times a slow down in my project. It seems that passing individual files to rustfmt is much slower than letting it handle multiple files at the same time in parallel.

[bradzacher]

yeah I noticed the same thing with some other formatters - dprint-plugin-exec essentially runs "for each file, read file from disk, pass to exec formatter, read format result from output"

This ofc means that you pay the spin up / spin down cost for the executable - which is BRUTAL.

If we could do something like "pipe/pass list of files and expect a JSON response" then it would be much more efficient in every way.

[dsherret]

I'd recommend ensuring that incremental formatting is not disabled (don't have "incremental": false in the config file). It will be slower on the first run than dprint-plugin-rustfmt was, but after that it will only format files that have changed, which should be almost as fast as before. On the CI, there is a way to cache the incremental cache to also make it fast. Unfortunately there is a bug related to caching on GH actions (dprint/dprint#735) so after I fix that I will update and add some instructions here: https://dprint.dev/ci/

Unfortunately I have too many projects and so I had to cut back somehow. dprint-plugin-rustfmt was dropped because dealing with its upgrades became difficult and a drawback with using it was that running cargo fmt could differ whereas now with dprint-plugin-exec the two can be more easily aligned.

If we could do something like "pipe/pass list of files and expect a JSON response" then it would be much more efficient in every way.

The issue is that it needs to also work in an editor scenario where the file might not exist on the file system. Additionally, adding this introduces complexity both for dprint's plugin system and for users configuring the exec plugin because they'd have to provide a way to get executables to work with file paths and when formatting via stdin.

This ofc means that you pay the spin up / spin down cost for the executable - which is BRUTAL.

Yeah, this is why dprint-plugin-prettier and dprint-plugin-roslyn still exist. Languages like JS and C# (when not using AOT compilation) are too slow to startup, but rustfmt is fast enough.

[aminya]

I think archiving the repository and blocking any contribution is not the solution to the maintainace burden. Even if someone is interested in helping you, they cannot make a pull request.

https://github.com/dprint/dprint-plugin-rustfmt

Now, dprint is moving against the very reason I was using it: Fast formatting and built-in integration. I also do not understand this requirement that everything should run inside WASM. Why is that a requirement, and why is it worth damaging the ecosystem because of WASM?