This is the naive approach, which does not attempt to read files or compute diagnostics in parallel (unless there's some salsa magic I don't understand happening under the hood).
I was expecting this to be pretty slow, but on a codebase with 234 Nix files comprising 14,000 LOC, nil diagnostics **/*.nix completes in 33ms. (Compare this to parallel --max-args 1 nil diagnostics ::: **/*.nix, which takes a full 4 seconds.)
If we try nil diagnostics **/*.nix in nixpkgs, we get:
exec: Failed to execute process 'nil': the total size of the argument list and exported variables (1.5MB) exceeds the OS limit of 1MB.
Which was to be expected. Using find to execute nil diagnostics with as many arguments as possible (find . -path '*.nix' -exec nil diagnostics {} +) completes in just 6.5 seconds! (That's to analyze 32,800 files containing 3 million LOC.)
The comparable command for one-invocation-per-file (find . -path '*.nix' | parallel --pipe --cat -L 1 --max-args 1 nil diagnostics {}) takes... well, it's still running.
Closes #124.
This is the naive approach, which does not attempt to read files or compute diagnostics in parallel (unless there's some
salsamagic I don't understand happening under the hood).I was expecting this to be pretty slow, but on a codebase with 234 Nix files comprising 14,000 LOC,
nil diagnostics **/*.nixcompletes in 33ms. (Compare this toparallel --max-args 1 nil diagnostics ::: **/*.nix, which takes a full 4 seconds.)If we try
nil diagnostics **/*.nixinnixpkgs, we get:Which was to be expected. Using
findto executenil diagnosticswith as many arguments as possible (find . -path '*.nix' -exec nil diagnostics {} +) completes in just 6.5 seconds! (That's to analyze 32,800 files containing 3 million LOC.)The comparable command for one-invocation-per-file (
find . -path '*.nix' | parallel --pipe --cat -L 1 --max-args 1 nil diagnostics {}) takes... well, it's still running.