git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 08/10] t5401: speed up creation of many branches

From
Taylor Blau <me@ttaylorr.com>
Date
Nov 29, 2023, 22:25 UTC
Message-ID
<ZWe6VDZqW8zCzMNJ@nand.local>
In-Reply-To
<f674119c7801e355cd08a651450abd67947d7456.1701242407.git.ps@pks.im>
On Wed, Nov 29, 2023 at 08:25:09AM +0100, Patrick Steinhardt wrote:
Show 18 quoted lines
> One of the tests in t5401 creates a bunch of branches by calling
> git-branch(1) for every one of them. This is quite inefficient and takes
> a comparatively long time even on Unix systems where spawning processes
> is comparatively fast. Refactor it to instead use git-update-ref(1),
> which leads to an almost 10-fold speedup:
>
> ```
> Benchmark 1: ./t5401-update-hooks.sh (rev = HEAD)
>   Time (mean ± σ):     983.2 ms ±  97.6 ms    [User: 328.8 ms, System: 679.2 ms]
>   Range (min … max):   882.9 ms … 1078.0 ms    3 runs
>
> Benchmark 2: ./t5401-update-hooks.sh (rev = HEAD~)
>   Time (mean ± σ):      9.312 s ±  0.398 s    [User: 2.766 s, System: 6.617 s]
>   Range (min … max):    8.885 s …  9.674 s    3 runs
>
> Summary
>   ./t5401-update-hooks.sh (rev = HEAD) ran
>     9.47 ± 1.02 times faster than ./t5401-update-hooks.sh (rev = HEAD~)
Very nice ;-).
Show 14 quoted lines
> diff --git a/t/t5401-update-hooks.sh b/t/t5401-update-hooks.sh
> index 001b7a17ad..8b8bc47dc0 100755
> --- a/t/t5401-update-hooks.sh
> +++ b/t/t5401-update-hooks.sh
> @@ -133,10 +133,8 @@ test_expect_success 'pre-receive hook that forgets to read its input' '
>  	EOF
>  	rm -f victim.git/hooks/update victim.git/hooks/post-update &&
>
> -	for v in $(test_seq 100 999)
> -	do
> -		git branch branch_$v main || return
> -	done &&
> +	printf "create refs/heads/branch_%d main\n" $(test_seq 100 999) >input &&
> +	git update-ref --stdin <input &&

Not that it really matters here, but you could pipe the output of your printf directly into git update-ref. I don't think we rely on the value of "input" after this point, and git is on the right-hand side of the pipe, so this is safe to do.

But it doesn't matter much either way, just something I noticed while reading.

Thanks, Taylor

Previous: Patrick SteinhardtNext: Patrick Steinhardt
Message 11 of 16 in “t: more compatibility fixes with reftables”
  1. 00/10 t: more compatibility fixes with reftablesPatrick Steinhardt, Nov 29, 2023
  2. 01/10 t0410: mark tests to require the reffiles backendPatrick Steinhardt, Nov 29, 2023
  3. Taylor BlauNov 29, 2023
  4. 02/10 t1400: split up generic reflog tests from the reffile-specific onesPatrick Steinhardt, Nov 29, 2023
  5. 03/10 t1401: stop treating FETCH_HEAD as real referencePatrick Steinhardt, Nov 29, 2023
  6. 04/10 t1410: use test-tool to create empty reflogPatrick Steinhardt, Nov 29, 2023
  7. 05/10 t1417: make `reflog --updateref` tests backend agnosticPatrick Steinhardt, Nov 29, 2023
  8. 06/10 t3310: stop checking for reference existence via `test -f`Patrick Steinhardt, Nov 29, 2023
  9. 07/10 t4013: simplify magic parsing and drop "failure"Patrick Steinhardt, Nov 29, 2023
  10. 08/10 t5401: speed up creation of many branchesPatrick Steinhardt, Nov 29, 2023
  11. Taylor BlauNov 29, 2023
  12. 09/10 t5551: stop writing packed-refs directlyPatrick Steinhardt, Nov 29, 2023
  13. Taylor BlauNov 29, 2023
  14. 10/10 t6301: write invalid object ID via `test-tool ref-store`Patrick Steinhardt, Nov 29, 2023
  15. Taylor BlauNov 29, 2023
  16. Patrick SteinhardtNov 30, 2023

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.