Re: [PATCH v2 2/2] parseopt: check for duplicate long names and numerical options

From: Jeff King <peff@peff.net>
Date: Mar 2, 2026, 18:24 UTC
Message-ID: <20260302182402.GH28275@coredump.intra.peff.net>
In-Reply-To: <7c221132-c2ac-4c6f-9d89-72677a74beb5@web.de>

On Sat, Feb 28, 2026 at 12:28:39PM +0100, René Scharfe wrote:

Show 6 quoted lines

> > Your other email made me wonder how the sorted-array solution might
> > perform (patch below). It shaves off 2ms of those 10. Probably not worth
> > caring about for "-h" output (which is already spending another 5-10ms
> > to generate the output, versus a normal parse).
> Curious; sorting performs worse on my machine (Apple M1, 1 is 2cc719175,
> 2 is patch 2 v2, 3 is your patch on top):

Interesting. Different architectures, I guess (mine's an i9). It makes me feel better about not trying to micro-optimize the last couple nanoseconds, though. ;)

Show 11 quoted lines

> Benchmark 1: ./git_main rev-parse --parseopt -- -h <input
>   Time (mean ± σ):      77.5 ms ±   0.4 ms    [User: 73.1 ms, System: 3.5 ms]
>   Range (min … max):    76.8 ms …  78.5 ms    37 runs
> 
>   Warning: Ignoring non-zero exit code.
> 
> Benchmark 2: ./git_strset rev-parse --parseopt -- -h <input
>   Time (mean ± σ):      82.6 ms ±   0.3 ms    [User: 77.7 ms, System: 3.9 ms]
>   Range (min … max):    82.1 ms …  83.7 ms    34 runs
> 
>   Warning: Ignoring non-zero exit code.

Interesting that your absolute times are much higher than mine (by a factor of 4), but the absolute cost of the strset addition is smaller. I'm not sure if that's another architecture difference, or maybe just the other unrelated parts of the process startup are more expensive on macOS (syscalls, filesystem access, etc).

Anyway, now that it is only used for "-h" I don't think we need to care that much.

-Peff