patch[RFC] t/perf/p3400: speed up setup using fast-import

The setup phase in 't/perf/p3400-rebase.sh' generates 100 commits to simulate a noisy history. It currently uses a shell loop that invokes 'git add', 'git commit', 'test_seq', and 'sort' in each iteration. This makes the whole process slow.

Optimize the setup by using 'git fast-import' to generate the commit history in a single stream. Additionally, pre-compute the forward and reversed file contents to avoid repetitive execution of 'seq' and 'sort'.

Performance enhancement:
  Before: 29.045s
  After:  18.081s

Measured on Lenovo Yoga 2020, Ubuntu 24.04.

Signed-off-by: Tian Yuchen <a3205153416@gmail.com>
---
 t/perf/p3400-rebase.sh | 53 +++++++++++++++++++++++++++++-------------
 1 file changed, 37 insertions(+), 16 deletions(-)

I noticed that while the setup phase is much faster (as shown in the commit message), the actual rebase performance test regressed slightly by about 3 seconds (from ~2s to ~5s). I don't quite understand what led to this outcome.

Additionally, I haven't delved deeply into the technical details of `git fast-import`, and I'm not entirely sure if my approach is reasonable and compliant with the specifications.

I would greatly appreciate any guidance from those knowledgeable in these area!

Regards, Yuchen

Tian Yuchen <a3205153416@gmail.com> writes：

I highly suspect that git fast-import generate the packfile that is NOT delta compressed. According to git fast-import documentation:

Could this be the reason why it's even slower than handling “loose objects”? I'm working on it currently.

Regards, Yuchen

After adding 'git repack -a -d', the time does changed:
                original(no change)        patch v1          NEW
     real           29.845                       18.081           22.231
rebase            13.34                         14.94            12.78

It seems that the 'git repack -a -d' line does reduce runtime. However, the total duration has seen a noticeable performance regression. I'm still trying to figure it out.

With regards, Yuchen

The setup phase in 't/perf/p3400-rebase.sh' generates 100 commits to simulate a noisy history. It currently uses a shell loop that invokes 'git add', 'git commit', 'test_seq', and 'sort' in each iteration. This incurs significant overhead due to repeated process spawning.

Optimize the setup by using 'git fast-import' to generate the commit history in a single stream. Additionally, pre-compute the forward and reversed file contents to avoid repetitive execution of 'seq' and 'sort'.

To ensure the test measures rebase performance against a consistent object layout (rather than the suboptimal pack/loose objects created by the raw import), perform a full repack (`git repack -a -d`) at the end of the setup.

This reduces the setup time significantly while maintaining the validity of the subsequent performance tests.

Performance enhancement:
          Real         Rebase
  Before: 29.045s      13.34s
  After:  22.231s      12.78s

Measured on Lenovo Yoga 2020, Ubuntu 24.04.

Signed-off-by: Tian Yuchen <a3205153416@gmail.com>
---

Changes since v1:
- Added 'git repack -a -d' at the end of the setup phase.
- This fixes a performance regression observed in the subsequent rebase
  test, ensuring the object layout is normalized before testing.
- Updated setup timing in the commit message to reflect the repack overhead.

 t/perf/p3400-rebase.sh | 54 +++++++++++++++++++++++++++++-------------
 1 file changed, 38 insertions(+), 16 deletions(-)

Am 28.01.26 um 17:07 schrieb Tian Yuchen:

Remove another pipe with

	sort -nr content_fwd >content_rev &&

This is an incorrect use of `return` outside a function. This must be `|| exit 1` (or just `|| exit`) to actually break out of the loop.

Of course, the error code is ignored, because it is in the upstream of a pipe, so in order to fail the complete command, it would be necessary that the original error left an incorrect fast-import stream such that the down-stream `git fast-import` fails. Otherwise, the entire command can complete successfully in an unexpected way.

Maybe instead of a pipe, dump the stream into a temporary file, so that the loop's exit code can be captured?

-- Hannes

Am 30.01.26 um 07:41 schrieb Johannes Sixt:

I am wrong here, because my earlier tests were too narrow. This use of `return` actually does work as intended, because it happens inside a function. Neither the subshell nor being in the upstream of a pipe negates this fact.

The rest of the comment still stands, though.

-- Hannes

Johannes Sixt <j6t@kdbg.org> writes:

I agree with the outcome (i.e., we do not run test_seq twice) but not necessarily with the motivation (i.e., we do not assume test_seq may fail and care about its failure code, so no need to avoid pipes for the sake of avoiding pipes).

Good.

I like this suggestion. A temporary file, unless it is excessively large, has an additional advantage that it allows you to inspect after "git fast-import" dies on it.

On 28/01/2026 16:07, Tian Yuchen wrote:

That's a nice speedup in the test setup

You can keep the same author and committer as the original with

	test_tick &&
	echo "author $GIT_AUTHOR_NAME <$GIT_AUTHOR_EMAIL> $GIT_AUTHOR_DATE" &&
	echo "committer $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> 
$GIT_COMMITTER_DATE" &&

here and below

The commit message in the original is "commit$i-reverse", not "reversed"

As Johannes pointed out we'll ignore the any failure above. We can address that by adding "echo done" here and adding "--done" to "git fast-import" below. That will cause "git fast-import" to fail because if there is an error in the loop as the last line of input to fast-import will not be "done"

Thanks

Phillip

Hi Johannes, Hi Phillip,

Thanks a lot for the detailed review and the great suggestions!

@Johannes: I will adopt the 'sort -nr content_fwd' optimization to save a process.

@Phillip: Your point about the pipe swallowing the exit code is very
insightful. I will
 implement the '--done' protocol to ensure any failure in the loop
causes the test to fail.

I will also update the author/committer generation to use test_tick and the standard environment variables, and fix the "reversed" typo.

I will prepare and send a v3 patch shortly incorporating these changes.

Thanks, Tian Yuchen

The setup phase in 't/perf/p3400-rebase.sh' generates 100 commits to simulate a noisy history. It currently uses a shell loop that invokes 'git add', 'git commit', 'test_seq', and 'sort' in each iteration. This incurs significant overhead due to repeated process spawning.

Optimize the setup by using 'git fast-import' to generate the commit history in a single stream. Additionally, pre-compute the forward and reversed file contents to avoid repetitive execution of 'seq' and 'sort'.

To ensure the test measures rebase performance against a consistent object layout (rather than the suboptimal pack/loose objects created by the raw import), perform a full repack (`git repack -a -d`) at the end of the setup.

This reduces the setup time significantly while maintaining the validity of the subsequent performance tests.

Performance enhancement (Average value of 5 tests):
           Real        Rebase
  Before: 29.045s      13.34s
  After:  22.431s      12.98s

Measured on Lenovo Yoga 2020, Ubuntu 24.04.

Signed-off-by: Tian Yuchen <a3205153416@gmail.com>
---

Changes since v2:
- Optimized `content_rev` generation by sorting `content_fwd` directly (Johannes Sixt).
- Used `test_tick` and standard `$GIT_COMMITTER_*` variables for consistency (Phillip Wood).
- Fixed typo "reversed" -> "reverse" to match original test (Phillip Wood).
- Added "done" command and used `git fast-import --done` to prevent errors in the loop being ignored by the pipe (Phillip Wood).

 t/perf/p3400-rebase.sh | 56 ++++++++++++++++++++++++++++++------------
 1 file changed, 40 insertions(+), 16 deletions(-)

The setup phase in 't/perf/p3400-rebase.sh' generates 100 commits to simulate a noisy history. It currently uses a shell loop that invokes 'git add', 'git commit', 'test_seq', and 'sort' in each iteration. This incurs significant overhead due to repeated process spawning.

Optimize the setup by using 'git fast-import' to generate the commit history. Additionally, pre-compute the forward and reversed file contents to avoid repetitive execution of 'seq' and 'sort'.

To ensure the test measures rebase performance against a consistent object layout (rather than the suboptimal pack/loose objects created by the raw import), perform a full repack (`git repack -a -d`) at the end of the setup.

This reduces the setup time significantly while maintaining the validity of the subsequent performance tests.

Performance enhancement (Average value of 5 tests):
            Real        Rebase
  Before:  29.045s      13.34s
   After:  21.989s      12.84s

Measured on Lenovo Yoga 2020, Ubuntu 24.04.

Signed-off-by: Tian Yuchen <a3205153416@gmail.com>
---

Changes since v3:
- Refactored the fast-import generation to write to a temporary file 
  (`fast_import_stream`) instead of using a pipe. This allows for better 
  debugging if fast-import fails, as suggested by Johannes Sixt and 
  endorsed by Junio C Hamano.
- Switched from `return 1` to `exit 1` inside the subshell to correctly 
  propagate exit codes.
- Undid the unnecessary removal of a blank line.

 t/perf/p3400-rebase.sh | 53 ++++++++++++++++++++++++++++++------------
 1 file changed, 38 insertions(+), 15 deletions(-)

Tian Yuchen <a3205153416@gmail.com> writes:

Thanks.  Will replace.

Am 30.01.26 um 17:39 schrieb Tian Yuchen:

In this case, please also undo the unnecessary removal of a blank line at the end of the patch.

-- Hannes