Jan Mas Rovira 6fcc9f21d2 Improve performance of formatting a project (#2863) ... Currently formatting a project is equivalent to running `juvix format` on each individual file. Hence, the performance is quadratic wrt the number of modules in the project. This pr fixes that and we now we only process each module once. # Benchmark (1236% faster 🚀) Checking the standard library ``` hyperfine --warmup 1 'juvix format --check' 'juvix-main format --check' Benchmark 1: juvix format --check Time (mean ± σ): 450.6 ms ± 33.7 ms [User: 707.2 ms, System: 178.7 ms] Range (min … max): 396.0 ms … 497.0 ms 10 runs Benchmark 2: juvix-main format --check Time (mean ± σ): 6.019 s ± 0.267 s [User: 9.333 s, System: 1.512 s] Range (min … max): 5.598 s … 6.524 s 10 runs Summary juvix format --check ran 13.36 ± 1.16 times faster than juvix-main format --check ``` # Other changes: 1. The `EntryPoint` field `entryPointModulePath` is now optional. 2. I've introduced a new type `TopModulePathKey` which is analogous to `TopModulePath` but wihout location information. It is used in hashmap keys where the location in the key is never used. This is useful as we can now get a `TopModulePathKey` from a `Path Rel File`. 3. I've refactored the `_formatInput` field in `FormatOptions` so that it doesn't need to be a special case anymore. 4. I've introduced a new effect `Forcing` that allows to individually force fields of a record type with a convenient syntax. 5. I've refactored some of the constraints in scoping so that they only require `Reader Package` instead of `Reader EntryPoint`. 6. I've introduced a new type family so that local modules are no longer required to have `ModuleId` from their type. Before, they were assigned one, but it was never used. # Future work: 1. For project-wise formatting, the compilation is done in parallel, but the formatting is still done sequentially. That should be improved.		2024-07-01 18:05:24 +02:00
..
Positive.hs	Improve performance of formatting a project (#2863)	2024-07-01 18:05:24 +02:00