Avoiding invalidations of `min`/`max`

[kimikage]

The following methods with Vararg invalidate Base.min(a, b, c, xs...) and Base.max(a, b, c, xs...).

BenchmarkTools.jl/src/groups.jl

Lines 70 to 71 in 70d083e

	Base.min(groups::BenchmarkGroup...) = mapvals(min, groups...)
	Base.max(groups::BenchmarkGroup...) = mapvals(max, groups...)

I think the min and max with N > 2 arguments are very primitive methods, so we should avoid the invalidations.

Usually, the compilation time is not the target of benchmarks, and in this case, the invalidations are caused by specialization with the type defined in BenchmarkTools. Therefore the invalidation should not affect benchmark results. However, although I don't know the reasons, recompiling a precompiled method can lead to different native code, i.e. have side-effects.

A simple way to avoid the invalidations is to change the definitions to:

Base.min(g1::BenchmarkGroup, g2::BenchmarkGroup) = mapvals(min, g1, g2)
Base.max(g1::BenchmarkGroup, g2::BenchmarkGroup) = mapvals(max, g1, g2)

This may cause performance degradation, but we can also use minimum/maximum. IMO, reducing strange side-effects is more important.

[kimikage]

BTW, I haven't found a "simple" example where this really matters. I'm not sure why in some cases methods depend on the vararg min/max even though the arguments are deterministic.

Edit:
AFAIK, Colors.find_maximum_chroma will be invalidated. (The invalidation of find_maximum_chroma itself does not matter.) Currently, find_maximum_chroma has a problem of the type instability, but the type inference of min/max is done correctly. Even if the type instability is fixed, the methods will be invalidated.

[kimikage]

Since I still don't know the root cause, I will close this superficial issue.