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

Re: [PATCH v3 2/2] p0005-status: time status on very large repo

From
Thomas Gummerer <t.gummerer@gmail.com>
Date
Apr 6, 2017, 22:14 UTC
Message-ID
<20170406221453.GA32223@hank>
In-Reply-To
<20170406134508.31711-3-git@jeffhostetler.com>
On 04/06, git@jeffhostetler.com wrote:
Show 68 quoted lines
> From: Jeff Hostetler <jeffhost@microsoft.com>
> 
> Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>
> ---
>  t/perf/p0005-status.sh | 61 ++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 61 insertions(+)
>  create mode 100755 t/perf/p0005-status.sh
> 
> diff --git a/t/perf/p0005-status.sh b/t/perf/p0005-status.sh
> new file mode 100755
> index 0000000..704cebc
> --- /dev/null
> +++ b/t/perf/p0005-status.sh
> @@ -0,0 +1,61 @@
> +#!/bin/sh
> +
> +test_description="Tests performance of read-tree"
> +
> +. ./perf-lib.sh
> +
> +test_perf_default_repo
> +test_checkout_worktree
> +
> +## usage: dir depth width files
> +make_paths () {
> +	for f in $(seq $4)
> +	do
> +		echo $1/file$f
> +	done;
> +	if test $2 -gt 0;
> +	then
> +		for w in $(seq $3)
> +		do
> +			make_paths $1/dir$w $(($2 - 1)) $3 $4
> +		done
> +	fi
> +	return 0
> +}
> +
> +fill_index () {
> +	make_paths $1 $2 $3 $4 |
> +	sed "s/^/100644 $EMPTY_BLOB	/" |
> +	git update-index --index-info
> +	return 0
> +}
> +
> +br_work1=xxx_work1_xxx
> +dir_new=xxx_dir_xxx
> +
> +## (5, 10, 9) will create 999,999 files.
> +## (4, 10, 9) will create  99,999 files.
> +depth=5
> +width=10
> +files=9
> +
> +## Inflate the index with thousands of empty files and commit it.
> +## Use reset to actually populate the worktree.
> +test_expect_success 'inflate the index' '
> +	git reset --hard &&
> +	git branch $br_work1 &&
> +	git checkout $br_work1 &&
> +	fill_index $dir_new $depth $width $files &&
> +	git commit -m $br_work1 &&
> +	git reset --hard
> +'
> +
> +## The number of files in the branch.
> +nr_work1=$(git ls-files | wc -l)

The above seems to be repeated (or at least very similar to what you have in your other series [1]. Especially in this perf test wouldn't it be better just use test_perf_large_repo, and let whoever runs the test decide what constitutes a large repository for them?

The other advantage of that would be that it is more of a real-world scenario, instead of a synthetic distribution of the files, which would give us some better results I think.

Is there anything I'm missing that would make using test_perf_large_repo not a good option here?

[1]: http://public-inbox.org/git/20170406163442.36463-3-git@jeffhostetler.com/
Show 9 quoted lines
> +test_perf "read-tree status work1 ($nr_work1)" '
> +	git read-tree HEAD &&
> +	git status
> +'
> +
> +test_done
> -- 
> 2.9.3
> 
Previous: git@jeffhostetler.comNext: Jeff Hostetler
Message 3 of 6 in “string-list: use ALLOC_GROW macro when reallocing”
  1. 0/2 string-list: use ALLOC_GROW macro when reallocinggit@jeffhostetler.com, Apr 6, 2017
  2. 2/2 p0005-status: time status on very large repogit@jeffhostetler.com, Apr 6, 2017
  3. Thomas GummererApr 6, 2017
  4. Jeff HostetlerApr 6, 2017
  5. Thomas GummererApr 6, 2017
  6. 1/2 string-list: use ALLOC_GROW macro when reallocing string_listgit@jeffhostetler.com, Apr 6, 2017

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.