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

[Jeff King <peff@peff.net>]

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

> > 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. ;)

> 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