Another issue is that the UX of

--per-file-caching

is obnoxious on cold runs, soooo much verbose output

But that messes with other systems (like stats log and show target labels)

I guess we need to finish releasing that fix, oops. We keep slipping in more fixes

But yeah I'm using log levels per target for the whitelisting

And yeah I wonder if there's another possible partitioning scheme of (pick a magic constant) 1.5-2-ish processes-per-core total (running on the unlinted) The multiplier ensures one process doesn't become a tentpole. And over a sufficient number of runs, it acts much like per-file process, as the cache fills up with chunks of files

And doesn't require synthetic results

So coming back to this, and on topic... In the cold case, doing

fmt-process-per-file

is always faster. In the hot case, doing

fmt-process-per-file

is actually slower, with the results increasing in time as the # of files go up (which makes sense)

Screenshot from 2022-01-05 09-56-47.png

As a baseline, running

yapf

and

isort

directly on the repo (with parellelization) takes roughly 22 seconds

So I guess the takeaway here is if you're using

--changed-since

it might not matter that much (until batching or similar is implemented). Probably go with all-in-one. Otherwise, if you're running on the world (perhaps in CI) then process-per-file is a good idea