Yuya Nishihara 042d26049c working_copy: lazily construct file_states BTreeMap ... While it got faster to build a large BTreeMap<RepoPath, _>, there's still a measurable cost. Let's eliminate it if watchman is enabled and the working copy is clean. Perhaps, we should introduce new serialization format that supports instant loading and lookup, but this hack works for the moment. I'm not sure if the new tree_state format should be flat (RepoPath, _) list, or tree like the backend storage btw. In my "linux" repo (watchman enabled): % hyperfine --sort command --warmup 3 --runs 10 -L bin jj-0,jj-1 \ "target/release-with-debug/{bin} -R ~/mirrors/linux status" Benchmark 1: target/release-with-debug/jj-0 -R ~/mirrors/linux status Time (mean ± σ): 768.9 ms ± 14.2 ms [User: 630.7 ms, System: 131.2 ms] Range (min … max): 742.3 ms … 783.1 ms 10 runs Benchmark 2: target/release-with-debug/jj-1 -R ~/mirrors/linux status Time (mean ± σ): 713.0 ms ± 16.8 ms [User: 587.9 ms, System: 116.2 ms] Range (min … max): 681.5 ms … 731.1 ms 10 runs Relative speed comparison 1.08 ± 0.03 target/release-with-debug/jj-0 -R ~/mirrors/linux status 1.00 target/release-with-debug/jj-1 -R ~/mirrors/linux status		2023-11-23 18:48:14 +09:00
..
benches
gen-protos
src	working_copy: lazily construct file_states BTreeMap	2023-11-23 18:48:14 +09:00
tests
testutils
Cargo.toml
LICENSE