Re: rev-list perf bug, some `git bugreport` version information:

[System Info]
git version:
git version 2.50.0.714.g196bf9f422-goog
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
libcurl: 8.13.0
OpenSSL: OpenSSL 3.4.1 11 Feb 2025
zlib: 1.3.1
SHA-1: SHA1_DC
SHA-256: SHA256_BLK
compiler info: gnuc: 14.2
libc info: glibc: 2.41

On Mon, Jun 23, 2025 at 1:58 PM Kai Koponen [off-list ref] wrote:

Reproduce steps:

git clone https://github.com/golang/go.git
cd go
git config core.commitGraph true
git commit-graph write --split --reachable --changed-paths  # Without
this, all calls equally slow (~1s)
time git rev-list -10 3730814f2f2bf24550920c39a16841583de2dac1 --
src/clean.bash > /dev/null  # ~90ms
time git rev-list -10 3730814f2f2bf24550920c39a16841583de2dac1 --
src/Make.dist > /dev/null  # ~100ms
time git rev-list -10 3730814f2f2bf24550920c39a16841583de2dac1 --
src/clean.bash src/Make.dist > /dev/null  # ~650ms

The rev-list call with multiple paths takes over 3x longer than the
sum of individual calls to it for the same files.

Expectation: rev-list with multiple paths should take <= the sum of
the time it takes to call it with each path individually (ideally <,
since with the count limit it should be able to early-exit and search
less commits for either path).

Also reproduces without the -10 arg, or with a lower count (double
instead of triple w/ -1), but these results are perhaps most
surprising with a count present.