Re: [PATCH 6/8] t/perf: add Scalar performance tests
- From
Victoria Dye <vdye@github.com>
- Date
- Sep 1, 2022, 16:15 UTC
- Message-ID
- <586fc6ca-b699-14a9-c5a1-10323a1cde0c@github.com>
- In-Reply-To
- <59s7o8n8-5797-q2qo-4q0o-93qppnr92q52@tzk.qr>
Johannes Schindelin wrote:
Show 48 quoted lines
> Hi Victoria,
>
> On Wed, 31 Aug 2022, Victoria Dye via GitGitGadget wrote:
>
>> [...]
>> +
>> +test_compare_perf () {
>> + command="$@"
>> + test_perf "$command (scalar)" "
>> + (
>> + cd scalar-clone/src &&
>> + $command
>> + )
>> + "
>> +
>> + test_perf "$command (non-scalar)" "
>> + (
>> + cd git-clone &&
>> + $command
>> + )
>> + "
>> +}
>> +
>> +test_compare_perf git status
>> +test_compare_perf test_commit --append --no-tag A
>
> Given the small numbers presented in the commit message, I suspect that
> even so much as running the command in a subshell might skew the timings
> at least on Windows, where subshells are very, very expensive.
>
> Given that both `git` and `test_commit` understand the `-C <directory>`
> syntax, this variant would resolve my concern:
>
> test_compare_perf () {
> command=$1
> shift
> args="$*"
>
> test_perf "$command (scalar)" "
> $command -C scalar-clone/src $args
> "
>
> test_perf "$command (non-scalar)" "
> $command -C git-clone $args
> "
> }
>
> What do you think?Makes sense to me! Although, out of curiosity, is there a reason you prefer "$1 -> shift -> $*" over '$1' and '$@'?
> > Ciao, > Dscho