In my practice, using three-arities of less/greater operations is pretty common for e.g. checking a number is in range:
The problem is, it is almost three times as slow compared to (and (< 0 temp) (< temp 100)).
This happens because three-arities are handled by the generic vararg arity branch:
This patch adds special handling for three-arities to these fns: < <= > >= = == not=
The performance gains are quite significant:
Higher arities also become faster, mainly because there's one less iteration now:
This patch also changes vararg artity of not= to use next/recur instead of apply:
Results are good:
I'm also doing what did in CLJ-1912 (calculating (next more) just once), although perf gains from that alone are not that big.
My point here is that optimizing three-arities makes sence because they appear in the real code quite often. Higher arities (4 and more) are much less widespread.