When designing a (performant) method with variable parameter length like
<T> void consume(T t1)
<T> void consume(T t1, T t2)
<T> void consume(T t1, T t2, T t3)
and a) another overload with vararg at the end e.g. ImmutableList.of()
<T> void consume(T t1, T t2, T t3, T... others)
or b) another overload with single vararg parameter e.g. List.of()
<T> void consume(T... tees)
What are the advantages and disadvantages of each vararg overload?
5
The problem with void consume(T... tees) is that it’s all syntax sugar. This:
void consume(T... tees) {
....
}
consume(a, b);
is that this is compiled to:
void consume(T... tees) {
....
}
consume(new Object[] {a, b});
and the ‘cost’ is the creation of that 2-element array. This isn’t a high cost, and in general ‘performant’ is simply not something you can reason out like this: Hotspot is far, far more complex than you think it is, so, you really need a profiler report before you just blindly assuming that making that 2-args array is actually a performance issue.
The point of having a stack of methods with increasing amounts of arguments until you get to the varargs one is that you avoid this array creation. However, the style you show is slightly wrong. This is right:
void consume(T a) { ??? }
void consume(T a, T b) { ??? }
void consume(T a, T b, T c, T... rest) { ??? }
In other words, you keep adding an argument, and once you feel you’ve got enough, the last one also gets the T... rest. You don’t want both consume(T a, T b, T c) as well as (T a, T b, T c, T... rest) because that means a call of the form consume(x, y, z) is ambiguous (are you calling the first one, or the second one with zero ‘rest’ args, which is valid java?)
So when do you ‘stop’ and just go with varargs? Well, you tell me: When the point of trying to save on that array allocation is no longer worth doing; some combination of ‘if you’re passing a bajillion args anyway, performance is probably out the window’ and ‘passing 12 args to this method is extremely rare so not worth trying to optimize for’.
In general you should just write one method (consume(T... tees)) and not bother with all those overloads. The JVM is very good at optimizing common patterns, and varargs are a very common pattern. Having the overloads is annoying to maintain, harder to document, and also adds API annoyances – if I happen to have an array of T elements I Can now no longer call your API.
5