Christian Couder <christian.couder@xxxxxxxxx> writes: >> The performance for `git cat-file --batch-all-objects --batch >> >/dev/null` on the Git repository itself with performance testing >> tool `time` change from "27.37s user 0.29s system 98% cpu 28.089 >> total" to "33.69s user 1.54s system 87% cpu 40.258 total". > > Saying that a later patch will add a fast path which will mitigate the > performance regression introduced by this patch might help reassure > reviewers. More importantly, why is such a fast-path even needed? Isn't it a sign that the ref-filter implementation is eating more cycles than it should for given set of placeholders? Do we know where the extra cycles goes? I find it somewhat alarming if we are talking about "fast-path" workaround before understanding why we are seeing slowdown in the first place.