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 <kaikoponen@xxxxxxxxxx> 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.
