Closed michaelpj closed 2 months ago
Note: I tried running the formatter once per-file in parallel using fd
, and it wasn't much faster. So maybe there is another mystery here.
@michaelpj which version of treefmt
are you using?
In v2 we implemented a new approach:
1024
, at which point we fire off a go routine which will apply each formatter in sequence to the batch of paths. The errgroup
for applying the formatters is bounded by runtime.NumCPU()
. With all this in mind, you should already be seeing some concurrency.
If we allowed providing the batch size that could be used to reduce the batch size and further improve concurrency, sending smaller numbers of paths to ormolu
.
Ah, interesting. I am indeed on 0.6.1! I'll see if I can get the newer one.
I've created https://github.com/numtide/treefmt/issues/334 to follow up on the batch size
Is your feature request related to a problem? Please describe.
At work we use
treefmt
to callormolu
on ~2.5k Haskell files. This takes about 32 seconds.A natural improvement would be to format those files in parallel. At the moment, that would require changing the formatter.
The alternative would be for
treefmt
to handle the parallelism by running the formatter on each file individually. Then the formatter doesn't need to do anything.Describe the solution you'd like
Some way of specifying how
treefmt
should call the formatter. Here's one option:batchSize
option to a formatter, with no batch size meaning "infinite"batchSize
, call the formatter once with each batch, in parallel.Then:
Describe alternatives you've considered
Do nothing, expect formatters to handle this.